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An  internetwork  consists  of  heterogeneous  domains  managed  under  different  ad- 
ministrative authorities.  For  secure  interdomain  resource  sharing,  it  is  necessary  to  im- 
plement an  Interdomain  Access  Control  (lAC)  protocol  to  regulate  traffic  flow  between 
end  domains  and  transit  domains.  Control  of  traffic  flow  from  one  stub  (end)  domain  to 
another  must  carry  some  proof  of  authentication  and  authorization  to  exit  from,  enter  to, 
and  transit  through  a  domain.  This  authentication  and  authorization  proof  usually  needs 
cryptographic  encryption  and  decryption.  Thus,  safe  session  key  distribution  becomes  a 
preliminary  for  an  lAC  protocol  to  succeed.  A  key  assignment  scheme  for  internetwork 
domains  is  proposed  so  that  the  safe  session  key  distribution  can  be  accomplished. 

An  end-to-end  authentication  and  authorization  protocol  is  not  sufficient  unless  the 
policy  and  resource  requirements  at  all  transit  domains  are  also  considered.  This  issue  is 
closely  related  to  internetwork  routing  protocols.  Therefore,  when  designing  an  interdomain 
access  control  protocol  it  is  logical  to  integrate  the  protocol  with  underlying  network  routing 
facilities.  Interdomain  Policy  Routing  (IDPR)  suggested  by  RFC  1479  [24]  is  a  typical 
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such  routing  facility  for  current  packet  switched  networks.  Two  interdomain  access  control 
protocols,  KIAC  (Key-based  lAC)  and  TIAC  (Ticket-based  lAC),  axe  proposed.  Both 
protocols  can  be  built  on  top  of  IDPR. 

In  the  implementation  of  lAC  protocols  with  IDPR,  some  state  information  of  a 
connection  must  be  maintained  and  some  computation  must  be  performed  by  the  routers 
at  transit  domains.  This  perfectly  fits  the  emerging  active  network  and  mobile  agent 
technologies  with  the  store-compute-forward  networking  paradigm.  A  dynamic  interdomain 
path  setup  for  lAC  protocols  is  also  proposed  under  the  active  network  infrastructiure. 
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CHAPTER  1 
INTRODUCTION 

An  internetwork  is  composed  of  many  administrative  domains  (ADs).  Network 
trfiffic  flows  between  stub  ADs  through  intermediate  transit  ADs.  Since  stub  ADs  may  have 
competing  interests,  each  end-to-end  communication  session  between  two  hosts  in  difi'erent 
stub  domains  should  be  authenticated  and  authorized. 

Traditional  firewall  schemes  [4]  achieve  some  degree  of  interdomain  access  control. 
In  a  firewall  system,  network  traffic  filtering  is  performed  on  a  per-packet  basis  indepen- 
dently by  firewalls  in  each  domain.  The  authorization  process  for  every  packet  in  a  firewall 
may  be  time-consuming  due  to  complex  domain  policies  and  the  variety  of  the  requested 
types  of  service. 

This  research  concerns  establishing  secure  and  authorized  communication  sessions 
between  hosts  with  cooperating  domain  gateways  (routers)  along  the  communication  paths. 
Not  only  do  connection-oriented  interdomain  access  control  (lAC)  protocols  oflFer  more 
flexibility  and  implementation  efficiency  for  access  control  pohcies  than  do  firewalls,  they 
also  lower  the  internetwork  load  by  reducing  the  amount  of  allowable  traffic. 

End-to-end  interdomain  access  control  protocols  are  analogous  to  international 
travel.  To  travel  from  the  United  States  to  Germany  via  Prance,  a  traveler  needs  to  obtain 
a  US  passport,  an  entry  visa  to  Germany  and  possibly  a  transit  visa  for  stopping  over  in 
Prance.  Similarly,  a  packet  flowing  from  one  stub  domain  to  another  must  carry  some  proof 
of  authentication  and  authorization  to  exit  from,  enter  to  and  transit  through  a  domain. 
Several  such  protocols  (e.g.,  VISA  [7]  and  PASS  [16])  have  been  proposed.  Since  these 
protocols  are  connection-oriented,  they  consist  of  an  initialization  and  a  packet  forwarding 
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phases.  During  the  initiaUzation  phase,  the  protocols  establish  a  shared  session  key  be- 
tween two  stub  domains.  In  the  packet  forwarding  phase,  each  packet  carries  a  message 
authentication  code  (MAC)  [13]  signed  by  the  secret  session  key  to  prove  its  authenticity 
and  authorization  to  the  participating  domain  gateways.  Therefore,  a  secure  interdomain 
communication  session  strongly  relies  on  how  safely  the  session  key  can  be  distributed  to 
the  participating  domain  gateways  through  networks.  In  Chapter  2,  a  long  term  secret  key 
shared  between  every  two  neighbor  domain  gateways  is  assumed  so  that  the  session  key  can 
be  distributed  among  domain  gateways  in  an  encrypted  form  using  the  shared  secret  keys. 
This  assumption  is  not  attractive  because  some  critical  transit  backbone  domains  may  need 
to  maintain  a  large  number  of  secret  keys  if  there  are  many  neighbor  domains  connected  to 
them.  Therefore,  a  key  assignment  scheme  is  developed  in  which  each  node  (domain)  only 
needs  to  remember  two  keys.  The  key  assignment  scheme  is  described  in  Chapter  4,  and 
Chapter  5  demonstrates  how  the  scheme  can  be  utilized  in  interdomain  access  control. 

Interdomain  access  control  protocols  axe  intended  to  form  a  mandatory  control 
framework  for  all  network  applications  that  require  information  flow  across  heterogeneous 
domains.  Applications  such  as  remote  login,  file  transfer,  and  e-mail  fall  into  this  category 
and  can  be  enhanced  with  additional  security  using  an  lAC  protocol.  The  primary  mo- 
tivation behind  an  lAC  mechanism  is  to  control  access  to  valuable  network  resources.  In 
the  context  of  interdomain  communication,  not  only  are  the  stub  ADs'  network  resources 
valuable,  but  also  the  transit  AOs'.  Access  control  schemes  such  as  VISA  and  PASS  focus 
only  on  access  control  to  the  stub  domains;  transit  domain  gateways  perform  no  active  role 
in  these  protocols.  Other  protocols  such  as  the  Packet  Level  Access  Control  by  Iqbal  [12] 
take  transit  domains  into  consideration.  However,  this  protocol  does  not  address  rout- 
ing decisions  in  a  dynamic  routing  environment.  Routing  decisions  in  transit  domains  are 
separated  from  the  access  control  between  stub  domains. 
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To  establish  a  feasible  communication  path  between  two  stub  domains,  the  local 
routing  pohcy  in  each  transit  domain  must  be  considered.  Many  policy  routing  proto- 
cols [24,  21,  19,  18]  exist.  We  use  the  interdomain  poUcy  routing  (IDPR)  in  our  proposed 
lAC  protocols  in  Chapter  2  to  integrate  the  implementation  of  end-to-end  access  control 
with  policy  routing  in  transit  domains,  though  any  of  these  protocols  would  suflBce. 

The  Path  Setup  and  Packet  Forwarding  protocols  in  IDPR  are  closely  related  to 
interdomain  access  control.  The  Path  Setup  protocol  is  responsible  for  computing  a  commu- 
nication path  based  on  the  routing  policies  contained  in  the  routing  information  databases 
(RIDs),  and  distributing  a  Path  ID  to  each  of  the  involved  domain  (stub  and  transit)  Pol- 
icy Gateways  (routers)  along  the  communication  path.  In  the  Packet  Forwajding  protocol, 
every  data  packet  is  checked  against  the  Path  IDs  stored  in  the  forwarding  information 
database  (FID).  Only  packets  with  a  valid  Path  ID  are  let  through. 

Path  IDs  are  for  routing  purposes  only.  They  cannot  be  used  to  compute  MACs 
to  protect  against  spoofing  or  illegal  modification  of  packets.  Our  first  secure  interdomain 
access  control  protocol  key-based  lAC  (KIAC),  presented  in  Chapter  2,  is  a  straightforward 
extension  of  IDPR  with  secret  session  keys  in  place  of  Path  IDs.  RIDs  and  FIDs  are  the  two 
primary  sources  of  storage  overhead  in  the  implementation  of  IDPR  and  KIAC.  Because  of 
these,  interdomain  routing  and  access  control  does  not  scale  well.  Many  approaches  have 
been  proposed  (superdomain  in  [24,  18],  viewserver  hierarchy  in  [2],  and  landmark  hierarchy 
in  [29])  to  reduce  the  RID  overhead.  Our  second  secure  interdomain  access  control  protocol 
ticket-based  lAC  (TIAC),  presented  in  Chapter  2,  eliminates  the  FID  storage  overhead. 

Both  KIAC  and  TIAC  are  built  on  top  of  IDPR,  which  builds  a  communication 
path  using  a  static  path  determination  strategy.  The  static  path  determination  strategy 
means  that  only  the  source  router  determines  the  path.  In  order  to  achieve  this,  each  router 
should  maintain  a  consistent  RID  that  contains  the  connectivity  of  the  internetwork  and  the 


4 


associated  domain  policies  of  each  node  so  that  a  feasible  path  can  be  computed.  The  large 
storage  overhead  of  RIDs  and  the  difficulty  of  maintaining  the  RIDs'  consistency  among 
routers  make  this  approach  scale  poorly.  Therefore,  a  dynamic  interdomain  communication 
path  setup  protocol  using  a  dynamic  path  determination  strategy  is  proposed  in  Chapter 
3  to  eliminate  the  necessity  of  RIDs.  In  contrEist  to  the  static  approach,  the  dynamic 
approach  shifts  the  path  determination  from  one  node  to  a  set  of  nodes,  or  from  centralized 
to  distributed.  Another  dynamic  featiu"e  of  this  protocol  is  that  a  path  can  be  reconfigured 
to  bypass  a  failed  or  congested  router/link. 

The  dynamic  functionality  of  the  proposed  protocol  greatly  increases  the  computa- 
tional responsibility  of  the  intermediate  network  nodes.  This  coincides  perfectly  with  the 
network  resolution  trend  from  passive  data  network  to  active  network  [26,  25,  32,  3]  in  which 
the  network  is  treated  as  a  computing  engine.  In  the  lAC  protocols,  some  state  information 
about  a  connection  must  be  maintained  and  some  computation  must  be  performed  by  the 
routers  at  transit  domains.  This  leads  to  investigation  of  the  emerging  active  network  and 
mobile  agent  technologies  for  the  implementation  of  lAC  protocols. 

The  active  network  is  a  revolutionary  concept  that  assumes  a  store-compute-forward 
networking  paradigm.  Packets  traversing  the  Internet  are  allowed  to  carry  both  program 
and  data.  At  each  network  node  that  a  packet  visits,  the  program  is  executed  on  the  data 
and  local  state,  possibly  leaving  some  state  information  for  subsequent  packets,  before  the 
resulting  packet(s)  is  forwarded  to  the  next  node.  In  effect,  each  router  actively  performs 
some  network/application-related  computation  in  addition  to  traditional  routing.  In  this 
scheme,  the  programs  are  similar  to  mobile  agents  that  are  interpreted  at  each  network 
node.  The  entire  network  becomes  programmable.  An  immediate  benefit  is  that  new 
protocols  (including  lAC)  can  be  deployed  easily  and  co-exist  with  existing  protocols.  Many 
innovative  apphcations  such  as  Web  caching  and  network  multicasting  also  can  be  effectively 
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supported  by  an  eictive  network.  Therefore,  we  believe  that  active  networks  provide  the 
most  suitable  network  infrastructure  to  implement  the  proposed  dynamic  protocol  for  secure 
access  control  over  the  Internet. 


CHAPTER  2 

INTERDOMAIN  ACCESS  CONTROL  WITH  POLICY  ROUTING 

This  chapter  proposes  two  secure  interdomain  access  control  protocols  that  are  inte- 
grated with  an  interdomain  policy  routing  protocol.  With  the  ability  to  compute  a  feasible 
communication  path  in  advance,  each  domain  policy  gateway  (PG)  can  build  a  logical 
connection  along  the  path  in  the  initialization  phase.  Thus,  not  only  can  the  stub  admin- 
istrative domains  (ADs)  enforce  their  policies,  so  can  the  transit  ADs.  Traffic  flow  control 
over  all  domain  PG  in  the  path  is  desirable  in  a  heterogeneous  internetwork  environment. 
This  can  prevent  the  unpredictable  behavior  of  dropping  packets  by  transit  PGs.  The 
packet  dropping  problem  occurs  on  VISA,  PASS,  and  any  other  protocol  that  only  builds 
a  logical  connection  for  two  stub  ADs. 

Key-based  and  ticket-based  interdomain  access  control  (KIAC,  TIAC)  protocols 
provide  a  uniform  and  more  efficient  way  to  achieve  integrity,  authenticity,  and  privacy 
than  interdomain  policy  routing  (IDPR).  Both  IDPR  and  KIAC  suffier  from  heavy  memory 
overhead  in  PGs.  For  some  topologically  critical  transit  PGs,  this  memory  overhead  will 
become  huge  and  unmanageable.  TIAC  is  designed  to  eUminate  this  memory  overhead 
without  significantly  degrading  the  performance  and  security. 

The  chapter  is  organized  as  follows:  Section  2.1  describes  the  basics  of  the  IDPR 
Path  Setup  and  Packet  Forwarding  protocols.  Section  2.2  presents  the  proposed  secure 
interdomain  access  control  protocols,  KIAC  and  TIAC.  Section  2.3  compares  the  perfor- 
mance overhead  of  the  two  protocols  in  terms  of  network  load,  cryptographic  computation 
and  key  searching  complexities.  A  summary  is  given  in  Section  2.4. 
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2.1    InterDomain  Policy  Routing  (IDPR) 

A  policy  route  (PR)  or  path  in  IDPR  is  a  sequence  of  domain  PGs.  Under  the 

IDPR  architecture,  each  domain  PG  maintains  a  routing  information  database  (RID)  which 

contains  transit  policies  (transit  service  offered)  for  all  other  domains  in  the  internetwork. 

With  this  database  in  hand  and  type  of  service  requested,  each  domain  PG  has  the  ability 

to  compute  a  feasible  PR  for  any  interdomain  traffic  flow,  if  one  exists.  Based  on  a  PR,  the 

Path  Setup  Protocol  establishes  the  actual  communication  path.  The  routing  information 

is  contained  in  the  FID  for  use  by  the  Packet  Forwarding  Protocol.  We  will  briefly  describe 

these  two  protocols  in  the  following  subsections. 
2.1.1    Path  Setup  Protocol 

Assume  a  generic  internetwork  topology  as  shown  in  Figure  2.1.  When  host  Ha 
in  domain  Di  wishes  to  communicate  with  host  Hb  in  domain  Z)„,  Ha  sends  out  a  data 
packet  with  destination  address  Hb.  This  data  packet  will  be  forwarded  within  Di  by  an 
intradomain  routing  protocol.  Eventually,  it  will  reach  PGi  in  Di.  Note  that  PGs  are  the 
only  entry  or  exit  points  for  a  domain. 


Domain  D  i  Domain  D  „ 

Figure  2.1.  Host  Ha  communicates  with  Host  Hb 


PGi  uses  the  data  packet's  header,  including  source  and  destination  addresses,  to 
determine  whether  it  is  an  interdomain  data  packet.  If  it  is  indeed  an  interdomain  data 
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packet,  PGi  will  first  try  to  locate  an  entry  in  its  own  FID  for  this  data  packet.  It  uses 
some  information  (Path  ID,  source/destination  addresses)  in  the  data  packet's  header  as 
search  indices.  This  search  will  result  in  an  entry  for  an  existing  traffic  flow,  or  fail  in  case 
of  a  new  traffic  flow.  If  an  entry  is  found,  PGi  forwards  this  data  packet  according  to  the 
entry.  The  format  of  the  FID's  entry  is  shown  in  Table  2.1.  Path  ID  field  contains  a  unique 
path  identifier  for  a  traffic  flow.  Src  (Dest)  Host  field  specifies  the  source  (destination)  host 
address.  Prev  (Next)  PG  field  specifies  the  previous  (next)  PG  in  the  PR.  The  last  field, 
Next  Hop,  indicates  the  next  router  to  which  this  traffic  flow  should  be  forwarded. 


Table  2.1.  Format  of  FID  entry  in  IDPR 


Path 

Src 

Dest 

Prev 

Next 

Next 

ID 

Host 

Host 

PG 

PG 

Hop 

If  no  entry  is  found  in  the  FID,  PGi  generates  a  feasible  PR  by  consulting  transit 
domains  policies  in  its  RID.  The  computation  of  PR  uses  inputs  such  as  source/destination 
domain  identifiers,  requested  service,  source  domain  poHcy,  and  transit  domain  policies. 
Based  on  this  computed  PR,  PGi  starts  to  set  up  the  communication  path.  Without  loss 
of  generality,  we  assume  the  PR  is  PG1-PG2-PG3. . .  PGn  (see  Figure  2.1). 

The  path  setup  works  as  follows:  PG\  invents  a  new  Path  ID  and  updates  its  FID 
by  adding  an  new  entry  for  this  Path.  Then,  PGi  sends  a  Path  Setup  message  to  PG2  with 
information  such  as  Path  ID,  PR,  requested  services,  and  source/destination  addresses. 
Upon  receiving  this  Path  Setup  message,  PG2  uses  information  in  this  message  to  check 
against  its  own  transit  policy  to  determine  whether  to  accept  or  reject  this  path.  In  case  of 
acceptance,  PG2  forwards  this  message  to  PG3  and  updates  its  FID  as  described  earher. 
This  procedure  continues  until  PG„  accepts  this  path  and  updates  its  FID.  Finally,  PG„ 
returns  an  ACCEPT  packet  all  the  way  back  to  PGi  in  the  reverse  direction  to  notify  all 
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PGs  in  the  path.  After  PGi  has  received  the  ACCEPT  packet  from  PG„,  each  PG  in  this 
route  should  have  an  entry  in  its  FID  corresponding  to  this  path.  Packet  forwarding  is 
ready  to  proceed.  Any  failure  during  this  path  setup  causes  a  REJECT  packet  to  be  sent 
back  to  PGi.  PG\  should  either  compute  another  feasible  PR  if  there  exists  one  or  send  a 

REJECT  packet  back  to  the  source  host  otherwise. 

2.1.2  Packet  Forwarding  Protocol 

Whether  Ha  should  possess  the  Path  ID  or  not  is  unspecified  in  the  IDPR  speci- 
fication. To  be  consistent  with  the  lAC  protocol  discussed  later,  we  assume  that  Ha  gets 
the  Path  ID  fi:om  PG\  during  Path  Setup.  Ha  attaches  the  Path  ID  to  every  data  packet 
bound  for  PG\  will  try  to  locate  a  FID  entry  using  the  Path  ID  as  an  index.  In 
case  of  success,  PG\  knows  the  next  PG  (in  this  example,  PG2)  through  which  this  data 
packet  should  travel.  PG\  encapsulates  the  received  data  packet  so  that  PG2  becomes  the 
destination  in  the  outer  header  and  forwards  this  encapsulated  packet  to  the  next  hop.  All 
other  PGs  perform  the  same  procedure  as  PG\.  Ultimately,  this  data  packet  reaches  the 

PGn  and  Hb  in  domain  Z?„. 

2.1.3  IDPR  Security 

The  IDPR  protocol  provides  an  INT/AUTH  header  field  for  integrity  and  authen- 
ticity purposes.  Thus,  all  IDPR  packets  can  be  protected  by  this  header  field  to  prevent 
address  spoofing  and  illegal  modification.  Note  that  the  piurpose  of  this  field  is  the  same 
as  the  message  authentication  code  (MAC)  we  use.  We  will  use  the  term  MAC  hereafter. 

Since  there  exists  no  session  key  shared  among  all  PGs  in  the  path,  the  MAC  of  a 
data  packet  needs  to  be  recomputed  with  the  shared  secret  key  between  peer  PGs.  This 
computational  overhead  can  be  significant. 
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2.1.4    IDPR  Summary 

IDPR  is  a  typical  policy  routing  protocol  that  entails  establishment  of  a  communi- 
cation path  using  a  static  path  determination  strategy.  Static  path  determination  means 
that  only  the  source  router  determines  the  path.  Each  router  must  maintain  a  consistent 
RID,  containing  the  connectivity  of  the  internetwork  and  the  associated  domain  pohcy  of 
every  node,  for  the  computation  of  feasible  paths.  Note  that  assuming  the  consistency 
among  all  RIDs  and  correctness  of  Path  Computation,  the  routing  path  computed  by  the 
source  router  for  a  communication  session  is  feasible  since  it  most  likely  will  be  agreed  on 
by  all  transit  routers.  Having  the  ability  to  compute  a  feasible  routing  path  in  a  source 
router,  the  path  setup  can  confidently  commence  without  the  fear  of  rejection. 

The  Path  Setup  protocol  is  responsible  for  setting  up  a  communication  path  based 
on  the  source  computed  PR,  and  distributing  a  Path  ID  to  each  of  the  involved  domain  PCs 
along  the  path.  In  the  Packet  Forwarding  protocol,  every  data  packet  is  checked  against 
the  Path  IDs  stored  in  the  FID.  Only  packets  with  a  valid  Path  ID  are  let  through. 

Path  IDs  are  for  routing  purposes  only.  They  cannot  be  used  to  compute  MACs  to 

protect  against  spoofing  or  illegal  modification  of  packets.  Therefore,  seciure  I  AC  protocols 

are  necessary  to  enhance  the  security  functionality  of  IDPR.  In  the  next  section,  two  such 

kind  of  protocols,  KIAC  and  TIAC,  are  proposed. 

2.2    Secure  Interdomain  Access  Control  Protocols 

In  the  IDPR  protocol,  each  packet's  authentication  and  integrity  are  achieved  by  a 
MAC  recomputation  at  each  domain  gateway  along  the  commimication  path.  This  perfor- 
mance overhead  can  be  reduced  if  there  is  a  shared  session  key  instead  of  a  path  ID.  In  this 
section,  two  protocols  KIAC  and  TIAC  with  different  approaches  of  sharing  session  keys 
are  addressed. 
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2.2.1    Assumptions  and  Notation 

Before  the  discussion  of  the  proposed  KIAC  and  TIAC  protocols  in  Sections  2.2.2 

and  2.2.3,  we  define  the  following  assumptions  and  notation. 

2.2.1.1  Assumptions 

The  assumptions  below  are  common  to  both  KIAC  and  TIAC. 

1.  The  proposed  protocols  are  based  on  a  symmetric  key  encryption  algorithm  to  ensure 

authenticity,  privacy,  and  integrity. 

2.  Every  PG  shares  a  secret  key  with  each  host  within  its  domain. 

3.  Adjacent  PCs  also  shaje  a  secret  key. 
4-  Each  PG  has  its  own  secret  key. 

5.  All  these  secret  keys  listed  above  are  already  in  place  and  stored  securely. 

Assumptions  2,  3,  4,  5  define  which  entity  should  share  a  secret  key  with  another  among  all 
PGs  and  hosts  in  a  PR  so  that  both  KIAC  and  TIAC  are  capable  of  distributing  a  session 

key  using  symmetric  encryption  algorithms. 

2.2.1.2  Notation 

We  will  illustrate  our  two  protocols  using  the  example  in  Figure  2.1.  The  notation 
used  in  this  section  is  given  below. 

Kai:  secret  key  shared  by  Ha  and  PGi 

K12:  secret  key  shared  by  PGi  and  PG2 

■f^(n-i)n-'  secret  key  shared  by  PGn-i  and  PG„ 
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Knb:  secret  key  shared  by  PG„  and  Hf, 

Ki:  secret  key  known  only  to  PGi,  for  i=l,  2, 3, . . . ,  n 

Ks :  secret  session  key  for  a  traffic  flow 

T^*„;  i-th  partial  ticket  generated  by  PGi  for  traffic  from  Hb  to  Ha,  for  i=l,  2, 3, . . . ,  n.  (If 
i  =  n  then  it  is  a  complete  ticket.) 

T^j,;  (n-i+l)th  partial  ticket  generated  by  PGi  for  traffic  from  Ha  to  Hb,  for  i=n,  n— 1, . . . ,  1. 
(If  i  =  1  then  it  is  a  complete  ticket.) 

MAC{K):  packet's  Message  Authentication  Code  is  a  signed  message  digest  of  the  packet's 
contents  using  key  K.  (K  is  one  of  the  above  peer  shared  secret  keys  or  Ks) 

E{X,K):  plaintext  X  encrypted  by  key  K. 

2.2.2    Key-based  Interdomain  Access  Control  Protocol  (KIAC) 

KIAC  is  a  straightforward  extension  of  IDPR  with  secret  session  keys  in  place  of 

Path  IDs  for  the  security  purpose.  An  initialization  and  a  packet  forwarding  phases  are 

corresponding  to  the  path  setup  and  the  packet  forwarding  protocols  in  IDPR  for  setting 

up  (initializing)  a  path  and  forwarding  data  packets. 

These  two  phases  are  described  in  the  following  two  sections. 
2.2.2.1  Initialization  Phase 

Five  control  messages  (with  message  contents  enclosed  in  curly  brackets)  are  used 
during  the  initiaUzation  phase.  A  REJECT  message  is  the  first  control  message  used  in  the 
protocol,  in  response  to  an  unauthorized  data  packet. 

1.  REJECT:  PGi  ^ 

{reason  for  rejection,  MkC{Kai)] 
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2.  AUTH-REQ:  Ha-^PGi; 

{Hb,  requested  service,  MAC(/Cqi)} 

3.  CONN-REQi^i+i)  :  Pd  PGi+i; 

{Ha,  Hb,  PR,  requested  service,  MAC(i£ri(i+i))},  for  i=l,2, . . .  ,n  -  1. 

I  CONN-CONi^i_i)  :  Pd  -)•  PGi-i; 

{F„,  Hb,  EiKs,  MAC(i<:(i_i)i)},  for  i=n,  n  -  1, . . . ,  2. 

5.  ii:£;y-F0i2W^yli?I>;  PG„     ifb;  {ifa,  E(ii:s,i<:„6),  MAC(ii:„6)},  or 
PGi  ^  i^a;  {^fft,  EiK,,Kai),  MAC(Xal)} 
H.  G,  G2  G„.,  G. 


Hb 


Time 


___DATA 

^KEJEd —  

__COTW-REQj2^ 

'"cOM^^CON^i 

"Kiv^ORWARD^ 

CONN-REQ 


CONN-CON 


CONN-REQ  („.„„ 


CONN-CON  ,^„.,) 


KEY-FORWARD 


Figure  2.2.  Illustration  of  the  connection  establishment  for  Ha  and  Hf, 

For  Ha  in  Di  to  communicate  with  Hb  in  D„,  Ha  sends  a  data  packet  bound 
for  Hb  (see  Figiure  2.2).  Since  this  data  packet  does  not  yet  have  proper  authorization 
(i.e.,  MAC{Ks)),  PGi  will  reject  it  with  a  REJECT  packet.  Upon  receiving  the  REJECT 
packet.  Ha  sends  an  authorization  request  AUTH-REQ  packet  to  PGi  indicating  its  request 
to  access  Hb-  PGi  starts  the  authorization  process  if  the  attached  MAC(A'ai)  in  AUTH- 
REQ  is  correct.  If  this  request  is  approved  by  the  authorization  process,  PGi  computes 
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a  feasible  PR:  {PG1-PG2-PG3. . .  PGn)  and  adds  an  entry  into  its  session  key  database 
(SKD)  with  the  Src/Dest  Host,  Prev/Next  PG,  Next  Hop,  and  Life  Time  fields.  Each  PG 
assigns  a  Life  Time  that  represents  the  duration  of  validity  of  this  communication  session. 
The  format  of  the  SKD  entry  is  shown  in  Table  2.2.  (Note  that  if  the  control  granularity 
is  per  communication  session  instead  of  per  host  pair.  Path  ID  can  be  added  as  in  IDPR.) 


Table  2.2.  Format  of  SKD  entry  in  KIAC 


Src 

Dest 

Prev 

Next 

Next 

Sess 

Life 

Host 

Host 

PG 

PG 

Hop 

Key 

Time 

After  the  SKD  entry  has  been  added,  PGi  sets  up  a  communication  path  by  sending 
a  connection  request  CONN-REQ12  packet  to  PG2  (the  next  PG  in  PR).  CONN-REQ12 
packet  contains  a  source/destination  address  pair,  PR,  and  requested  service  so  that  PG2 
has  enough  information  to  proceed  with  authorization.  Upon  receiving  the  CONN-REQ12, 
PG2  verifies  the  MAC(A'i2)  of  this  request  packet.  In  case  of  successful  MAC  verification, 
PG2  initiates  its  local  authorization  process.  The  authorization  process  will  return  a  nega- 
tive answer  only  if  PGis  RID  is  inconsistent  with  PG2S  policies,  since  the  computation  of 
the  PR  has  already  taken  all  transit  domains  policies  into  consideration.  This  is  the  main 
reason  why  we  integrate  interdomain  access  control  protocols  with  IDPR  (or  other  inter- 
domain  routing  protocols).  If  the  request  is  authorized,  PG2  adds  an  SKD  entry  and  fills 
in  fields  as  PGi  did,  and  continues  path  setup  by  sending  another  CONN-REQ23  packet 
to  PGz  containing  the  same  information  as  CONN-REQ12. 

The  same  procedure  is  repeated  until  PG„  receives  the  CONN-REQ(„_i)„  request 
packet.  As  other  PGs,  PGn  verifies  the  MkC{K(n-i)n)  first  and  makes  a  decision  whether 
to  accept  the  request.  If  the  request  is  approved,  PGn  invents  a  session  key  Ks-,  and  adds 
an  SKD  entry  with  all  fields.   At  this  point,  PGn  generates  a  connection  confirmation 
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CONN-CON„(„_i)  packet  back  to  PGn-i  containing  the  source/destination  host  address 
pair,  and  encrypted  session  key.  PGn-i  in  turn  generates  another  C0NN-C0N(„_i)(„_2) 
packet  and  sends  it  back  to  PGn-2-  These  connection  confirmation  packets  axe  propagated 
all  the  way  baick  to  PGi.  For  each  i,  PGi  checks  the  authenticity  and  integrity  of  the 
connection  confirmation  packet  by  verifying  the  MAC  and  fills  in  the  Session  Key  field  by 
decrypting  the  session  key  encrypted  with  -K^j(i+i)  and  then  reencrypting  it  with  -K'(i_i)t- 

Both  PG\  and  PG„  will  generate  a  KEY-FORWARD  packet  to  Ha  and  iff,,  respec- 
tively. KEY-FORWARD  packets  contain  the  host  address  of  the  peer  and  the  encrypted 
shared  session  key.  Like  PCs,  Ha  and  H\)  also  maintain  a  SKD  and  add  an  entry  when 

receiving  the  KEY-FORWARD  packet. 

2.2.2.2  Packet  Forwarding  Phase 

After  all  entities  have  a  SKD  entry  for  this  communication  path,  data  packet  flow 
commences.  Since  Ha  has  Kg  in  hand,  it  can  send  a  data  packet  attached  with  yLkC{Ks) 
without  fear  of  rejection.  Verifying  the  MAC(Ks)  is  enough  to  prove  the  data  packet's 
integrity  and  authenticity  (hence  authorization).  After  verification  the  packet  is  forwarded 

to  the  next  PG.  Eventually,  the  data  packet  will  reach  its  final  destination  Hi,. 

2.2.2.3  KIAC  Securitv 

The  MAC  of  each  control  and  data  packet  provides  the  authenticity  and  integrity 
checking  to  prevent  address  spoofing  and  illegal  modification.  The  session  key  is  encrypted 
using  peer  shared  secret  keys  in  the  initialization  phase  and  must  be  stored  securely.  Thus,  a 
malicious  eavesdropper  can  not  obtain  this  session  key  to  illegally  consume  valuable  network 
resources. 

Since  a  single  session  key  is  shared  among  all  entities  after  initialization,  the  compu- 
tation of  the  MAC  for  a  data  packet  takes  place  only  at  the  source  host.  It  is  not  necessary 
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for  every  PG  to  recompute  a  new  MAC.  Prom  this  point  of  view,  KIAC  is  more  efficient 
than  IDPR. 

2.2.3    Ticket-based  Interdomain  Access  Control  Protocol  (TIAO 

Tickets  used  in  this  protocol  are  encrypted  data  containing  the  session  key  and 
other  relevant  information.  Tickets  are  used  to  replace  the  SKD  entries  in  KIAC  thereby 
saving  space  at  all  intermediate  PCs.  Every  interdomain  data  packet  requires  a  valid  ticket 
to  pass  through  all  PCs.  In  order  to  verify  the  attached  MAC(i^j)  of  each  data  packet,  a 
PG  uses  the  peer  shared  secret  key  to  decrypt  the  ticket  and  obtain  the  session  key.  Thus, 
the  ticket  must  be  carefully  generated  such  that  it  can  be  decrypted  by  all  PCs.  Format  of 
the  partial/complete  tickets  is  shown  in  Table  2.3.  We  need  two  complete  tickets  for  a  two 
way  communication  session,  one  for  each  direction.  In  our  example,  T"j,  is  for  data  packets 
from  Ha  to  Hb,  Tj^  is  for  data  packets  from  Hi,  to  Ha- 


Table  2.3.  Format  of  (n-i-l-l)th  and  i-th  partial  Tickets 


Src 

Dest 

Next 

Sess 

Life- 

Prev  Partial 

Host 

Host 

PG 

Key 

Timej 

Ticket 

Ha 

Hb 

Src 

Dest 

Next 

Sess 

Life- 

Prev  Partial 

Host 

Host 

PG 

Key 

Timei 

Ticket 

PGi-x 

2.2.3.1  Initialization  Phase 

1.  REJECT:  PGi  Ha, 

{reason  for  rejection,  MAC(Kai)} 

2.  AUTH-REQ:  Ha^PGv, 

Hb,  {requested  service,  MAC{Kai)} 
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3.  CONN-REQi^i+i)  :  Pd  PGi+i; 

{Ha,  Hb,  PR,  requested  service,  E(T^„,  Ki^i+i)),  MAC{Ki^i+i))} ,  for  i=l,  2, . . . ,  n  -  1. 

I  CONN-CONi(i_i)  :  PGi  ^  PGi_i; 

{ffa,  Hb,  PR,  E(r4,i<:(,_i)i),  MAC(i<:(i_i)i)},  for  i=n,n-  1,...,2. 

5.  KEY-FORWARD:  PGn     Hb;  {Ha,  E{T^^,Kr^),  E{Ks,Knb),  MAC(/^„6)},  or 
PGi     Ha,  {Hb,  E{T^,Ki),  E{K„Kai),  MAC{Kai)} 

As  in  KIAC,  Ha  receives  a  REJECT  packet  from  PGi  because  it  sends  out  an 
interdomain  data  packet  without  a  proper  MAC{Ks).  Ha  sends  an  AUTH-REQ  packet 
to  PGi  containing  the  address  of  destination  host  Hb  and  requested  service.  PGi  checks 
the  validity  of  MAC(ifai)  in  AUTH-REQ  and  initiates  its  local  authorization.  If  accepted, 
PGi  computes  a  feasible  PR.  Meanwhile,  PGi  creates  a  session  key  and  forms  the  1st 
partial  ticket  TjJ,.  The  Next  PG  and  Previous  Partial  Ticket  fields  of  T^^^  should  be  empty 
or  padded  with  zeros  since  they  do  not  exist.  PGi  sends  a  CONN-REQ12  packet  to  PG2 
containing  the  encrypted  first  partial  ticket  E{T^^,Ki2). 

Each  intermediate  PGi  {i  —  2,3,...  n  -  1)  executes  the  following  sequence  of  steps 
after  receiving  a  CONN-REQ(i_i)i  packet: 

1)  Verify  the  MAC{K(i_i)i). 

2)  Authorize  the  request. 

3)  Decrypt  E{T^-\K^i_-^)i)  to  obtain  Ks. 

4)  Form  the  i-th  partial  ticket       and  encrypt  it  as  E{T^^,Ki^i^i-)). 

5)  Send  CONN-REQi(i+i)  to  PGj+i  with  the  same  information  as  CONN-REQ(i_i)j, 
but  with  newer  encrypted  i-th  partial  ticket. 

Finally,  PGn  also  executes  the  same  sequence  of  steps  from  1  to  3,  and  forms 
the  complete  ticket  T^^  and  the  opposite  direction  1st  partial  ticket  T^^.    PGn  sends 
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the  CONN-CON„(„_i)  packet  back  to  PGn-i  containing  the  encrypted  1st  partial  ticket 
E(r"ft,i<r(„_i)„)  along  with  other  information.  The  connection  confirmation  packets  are 
propagated  back  to  PGi  and  the  partial  ticket  will  grow  into  a  complete  ticket  at  PGi. 
As  in  KIAC,  both  PGi  and  PG„  will  send  the  KEY-FORWARD  packet  to  Ha  and  Hb  to 
distribute  the  complete  ticket.  Since  the  complete  tickets  are  encrypted  by  secret  keys  only 
known  to  the  end  PGs,  the  end  hosts  have  no  way  to  know  the  session  key  from  the  tickets. 
Thus,  the  session  key  also  should  be  distributed  to  end  hosts  in  KEY-FORWARD  packets. 
Note  that  only  two  end  hosts  Ha  and  Hb  need  to  maintain  the  SKD  in  this  protocol.  Format 
of  the  SKD  entry  at  the  end  hosts  is  shown  in  Table  2.4. 

Table  2.4.  Format  of  SKD  entry  in  TIAC 


Dest  Host    Session  Key    Encrypted  Ticket 


2.2.3.2  Packet  Forwarding  Phase 

Ha  starts  the  Packet  Forwarding  Phase  by  sending  data  packets  to  Hi,  with  an  en- 
crypted ticket  and  MAC{Ks).  Each  PG  can  decrypt  the  ticket  to  obtain  a  session  key,  and 
use  the  session  key  to  verify  the  MAC{Ks)  to  prove  the  data  packet's  integrity  and  au- 
thenticity (hence  authorization).  Next  PG  field  in  the  ticket  indicates  the  next  destination 
address  for  encapsulation.  The  Life-Time  field  in  the  ticket  ensures  that  this  ticket  has  not 
expired.  All  fields,  except  the  last  one  (Previous  Partial  Ticket),  are  stripped  off  by  each 
PG.  Since  the  ticket  will  be  shrunk  en  route,  the  computation  and  verification  ofMAC{Ks) 

for  the  data  packet  must  not  include  the  ticket. 

2.2.3.3  TIAC  Securitv 

An  encrypted  ticket  is  an  identity-based  capability.  Thus,  it  is  useful  only  for  the 
source  host.  Each  packet's  MAC  protects  against  address  spoofing  and  illegal  modification. 
Note  that  the  computation  of  the  MAC  does  not  include  the  ticket.   Therefore,  illegal 
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modification  of  this  ticket  cannot  be  detected  by  verifying  the  MAC.  Fortunately,  the 

encrypted  ticket  is  tamper-resistant  because  it  contains  the  Soiurce  Host  and  Destination 

Host  fields.  Every  PG  can  decrypt  the  ticket  and  compare  the  somrce/destination  addresses 

in  the  packet  header.  Any  modification  of  the  ticket  can  be  detected  if  the  match  fails. 

Destination  Host  field  in  the  ticket  also  can  be  used  to  prevent  malicious  ticket  usage  by 

the  source  host  to  communicate  with  other  hosts  within  the  same  destination  domain. 

2.3    Performance  Overhead 

The  analysis  of  performance  overhead  for  KIAC  and  TIAC  uses  the  following  quan- 
titative measurements: 

1.  Network  load  (NW):  number  of  packets  x  number  of  PGs  traversed 

2.  Computational  complexity  (COM):  number  of  encryptions  and  decryptions 

3.  Secret  key  searching  (SEC):  number  of  secret  key  database  searches 

4.  Session  key  searching  (SES):  number  of  session  key  database  searches 

The  following  assimiptions  are  also  used  in  the  analysis: 

1.  The  number  of  data  packets  for  a  communication  session  is  M. 

2.  There  are  N  policy  gateways  in  the  PR. 

3.  No  REJECT  packet  is  generated  for  this  communication  session. 

4.  The  assumptions  listed  in  section  2.2.1. 

Tables  2.5  and  2.6  summarize  the  overhead  of  the  initialization  and  packet  forward- 
ing phases,  respectively. 

The  results  indicate  that  TIAC  requires  more  computation  than  KIAC,  but  less 
key  searching.  Which  protocol  is  more  efficient  depends  on  various  factors  such  as  size  of 
database,  encryption  algorithm  used,  and  underlying  machine  architecture.  For  simphcity, 
if  we  assume  that  computation  is  comparable  to  key  searching,  then  the  overall  performance 
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Table  2.5.  Initialization  phase  overhead  comparison 


NW      COM      SEC  SES 

KIAC 
TIAC 

2iV  +  l    6iV  +  4    4iV  +  l  None 
2Ar  +  l    8iV  +  4    4iV  +  l  None 

Table  2.6.  Packet  Forwarding  phase  overhead  comparison 


NW 

COM 

SEC 

SES 

KIAC 

MN 

M{N  +  2) 

None 

M{N  +  2) 

TIAC 

MN 

M{2N  +  2) 

None 

2M 

overhead  for  TIAC  is  slightly  higher  than  KIAC.  However,  the  memory  overhead  of  TIAC 

is  greatly  reduced  because  the  required  information  is  shifted  from  local  memory  to  the 

ticket.  Another  performance  concern  for  TIAC  is  the  size  of  data  pjickets,  which  contain 

an  extra  ticket  beyond  the  MAC  included  in  KIAC  data  packets.  The  size  of  a  ticket  is 

approximately  200N  bits  (25N  bytes)  if  there  are  N  layers  in  the  ticket.  For  a  typically 

1000  to  1500  bytes  MTU  (Maximum  Transfer  Unit)  link,  the  ticket  could  comsume  ^  to 

bandwidth  in  the  link  for  a  data  packet.  In  TIAC,  the  number  of  layers  in  the  ticket  is 

equal  to  the  number  of  gateways  in  the  path  because  the  ticket  is  encrypted  layer  by  layer 

using  the  shared  secret  keys  between  every  two  neighbor  gateways.  Therefore,  the  ticket  in 

a  data  packet  could  consume  a  major  portion  of  the  link  bandwidth  if  the  path  is  long.  In 

Chapter  4,  we  develop  a  derivable  key  generation  scheme  that  can  be  used  to  assign  keys 

to  Internet  domain  gateways  to  replace  the  shared  secret  keys  between  every  two  neighbor 

domain  gateways.  Also  in  Chapter  5,  we  demonstrate  how  to  use  the  assigned  keys  to  form 

the  tickets  such  that  the  number  of  layers  is  at  most  three. 

2.4    Chapter  Summziry 

This  chapter  proposed  two  secure  interdomain  access  control  protocols  that  are 
integrated  with  an  interdomain  routing  protocol.  With  the  abiUty  to  compute  a  feasible 
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PR  in  advance,  a  PG  can  build  a  logical  connection  along  the  PR  in  the  initialization 
phase.  Thus,  not  only  can  the  stub  ADs  enforce  their  policies,  so  can  the  transit  ADs. 
Traffic  flow  control  over  all  PGs  in  the  route  is  desirable  in  a  heterogeneous  internetwork 
environment.  This  can  prevent  the  undesirable  behavior  of  dropping  packets  by  transit 
PGs  unpredictably.  The  paicket  dropping  problem  occurs  on  VISA,  PASS,  and  any  other 
protocol  that  only  builds  a  logical  connection  for  two  stub  ADs. 

KIAC  and  TIAC  protocols  provide  a  uniform  and  more  efficient  way  to  achieve 
integrity,  authenticity,  and  privacy  than  IDPR.  Both  IDPR  and  KIAC  suffer  from  heavy 
memory  overhead  in  PGs.  For  some  topologically  critical  transit  PGs,  this  memory  over- 
head will  become  huge  and  unmanageable.  TIAC  is  designed  to  eliminate  this  memory 
overhead  without  significantly  degrading  performance  and  security. 

Unfortunately,  a  new  network  protocol  generally  requires  a  lengthy  standardization 
process  before  it  caji  be  deployed  in  current  network  infrastructiure.  Furthermore,  the  RID 
memory  overhead  mentioned  eeirlier  also  restricts  their  practical  use  in  internetworks.  In 
Chapter  3,  a  dynamic  interdomain  access  control  protocol  in  active  networks  is  proposed 
to  eliminate  the  necessity  of  a  replicated  RID  and  its  deployment  c£in  be  immediate. 


CHAPTER  3 

DYNAMIC  INTERDOMAIN  PATH  SETUP  IN  ACTIVE  NETWORKS 

An  internetwork  is  composed  of  many  administrative  domains  (ADs)  with  different 
administrative  and  security  policies  for  protecting  their  own  valuable  resources.  A  network 
traffic  flow  between  stub  ADs  through  intermediate  transit  ADs  must  not  violate  any  stub 
or  transit  domain  policy.  Packets  may  be  dropped  by  routers  that  detect  a  policy  violation. 
Therefore,  it  is  necessary  for  a  communication  session  to  set  up  a  communication  path  in 
which  all  constituent  routers  are  willing  to  serve  for  the  session  so  that  data  packets  can 
be  delivered  safely  without  being  discarded. 

Moreover,  such  a  communication  path  cannot  guarantee  successful  packet  deliveries 
if  the  intermediate  routers/links  are  subject  to  failures  or  congestion.  A  dynamic  inter- 
domain  communication  path  setup  protocol  is  proposed  in  this  chapter  to  address  these 
issues.  The  protocol  is  dynamic  in  the  sense  that  the  path  determination  strategy  is  dis- 
tributed and  a  path  can  be  reconfigured  to  bypass  a  failed  or  congested  router/Unk.  These 
two  dynamic  features  require  the  intermediate  network  nodes  to  make  some  decisions  and 
computation.  The  implementation  of  the  protocol  relies  on  the  computational  capabil- 
ity of  active  networks  by  which  active  nodes  in  the  networks  can  provide  computation  in 
addition  to  traditional  communication.  Thus,  the  design  of  the  protocol  is  based  on  the 
assumption  of  the  active  network  architecture.  The  protocol  will  be  a  useful  tool  for  all 
connection-oriented  appHcations  in  active  networks. 

In  this  chapter,  Section  3.1  describes  the  interdomain  poUcy  routing  (IDPR)  static 
path  setup  protocol.  Section  3.2  briefly  discusses  the  architecture  of  active  networks.  Sec- 
tion 3.3  presents  the  dynamic  interdomain  path  setup  protocol  in  active  networks.  A 
summary  is  given  in  Section  3.4. 
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3.1    Static  Path  Setup  -  Policy  Routing 

IDPR  is  a  routing  protocol  designed  for  connection-oriented  interdomain  applica- 
tions. It  is  composed  of  three  primary  protocols. 

1.  Policy  Update  Protocol:  PUP  handles  reliable  flooding  of  link  state  updates  throughout 

the  internetwork. 

2.  Path  Setup  Protocol:  PSP  installs  and  maintains  routing  information  in  all  participating 

routers. 

3.  Packet  Forwarding  Protocol:  PFP  forwards  data  packets  along  a  previously  established 

path. 

In  IDPR,  each  router  has  a  routing  information  database  (RID)  for  storing  the 
network  topology  of  ADs  and  their  associated  transit  policies.  To  provide  a  consistent  view 
of  the  internetwork  among  all  routers,  the  Policy  Update  Protocol  maintains  the  consistency 
among  RIDs  by  using  a  reliable  flooding  of  Unk  state  updates  throughout  the  internetwork. 
Another  important  component  of  IDPR,  Path  Computation,  computes  the  routing  path 
in  accordance  with  soiurce  and  transit  domain  policies.  It  is  not  a  protocol  in  that  each 
domain  can  implement  its  own  version  of  Path  Computation  as  long  as  it  provides  the 
interfaces  to  other  protocols.  Note  that  assuming  the  consistency  among  all  RIDs  and 
correctness  of  Path  Computation,  the  routing  path  computed  by  the  source  router  for  a 
communication  session  is  feasible  since  it  most  likely  will  be  agreed  on  by  all  transit  routers. 
Thus,  an  interdomain  communication  protocol  can  be  implemented  using  the  underlying 
IDPR  policy  routing  facilities  to  determine  a  feasible  routing  path.  Having  the  abihty  to 
compute  a  feasible  routing  path  in  a  source  router,  the  path  setup  can  confidently  commence 
without  the  fear  of  rejection. 
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In  the  Path  Setup  protocol,  the  source  router  sends  out  a  Setup  packet  contain- 
ing the  computed  path.  Each  transit  router  receiving  this  Setup  packet  checks  its  local 
administrative  transit  policy  to  determine  whether  to  accept  or  reject  this  path.  In  case 
of  acceptance,  the  router  creates  an  entry  for  this  session  in  its  forwarding  information 
database  (FID).  The  purpose  of  this  FID  is  for  packet  forwarding.  An  entry  in  FID  con- 
sists of  a  path  ID,  previous  and  next  router  in  the  path,  and  other  useful  information.  After 
an  entry  in  FID  is  built,  the  router  forwards  the  Setup  packet  to  the  next  router  in  the 
path,  and  the  process  is  repeated  for  the  subsequent  routers. 

Once  a  path  has  been  setup  by  the  path  setup  protocol,  the  packet  forwarding 
protocol  forwards  the  user  data  packets  through  the  path.  Each  router  in  the  path  uses 
the  path  ID  and  packet's  MAC  to  check  the  authenticity  and  integrity  of  received  data 
packets.  For  data  packets  with  correct  verification,  the  router  forwards  them  to  the  next 
router  recorded  in  the  FID.  In  this  way,  all  data  packets  for  a  session  can  flow  through  the 
established  path  to  the  destination. 

IDPR  Path  Setup  is  static  because  the  path  is  determined  ahead  of  time  statically 

and  solely  by  the  source.  Each  transit  router  can  only  accept  or  reject  the  proposed  path. 

It  plays  no  role  in  the  path  computation.  This  violates  the  general  philosophy  that  the  one 

providing  the  service  should  make  the  decision.  Therefore,  a  dynamic  path  setup  protocol 

is  proposed  in  Section  3.3.  In  contrast  to  IDPR,  each  router  in  the  proposed  dynamic 

protocol  determines  the  next  segment  (router)  of  the  path. 

3.2    Active  Network  Architecture 

Active  networks  [26,  25,  32,  3]  are  a  novel  approach  to  network  architecture  in  which 
each  switch  in  the  network  provides  a  computation  environment  such  that  customized 
computation  can  be  performed  on  the  fly  based  on  the  messages  flowing  through  them. 
In  essence,  the  network  becomes  programmable  for  any  specific  application.  Currently,  a 
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new  network  protocol  generally  requires  a  lengthy  standardization  process  before  it  can  be 
deployed.  Under  an  active  network  architecture,  the  deployment  of  a  new  network  protocol 
can  be  immediate. 

Traditional  data  networks  passively  transport  packets  from  one  end  system  to  an- 
other. The  network  does  not  care  much  about  the  contents  of  the  packets  it  carries,  and 
they  are  transferred  between  end  systems  without  modification.  Computation  within  the 
network  is  limited,  e,g.,  header  processing  in  packet-switched  networks.  The  exponential 
growth  of  the  Internet  hcis  brought  diverse  applications  that  may  require  intermediate  net- 
work nodes  to  perform  some  computation  on  application  data.  For  example,  web  browsing 
can  be  enhanced  if  the  intermediate  nodes  support  web  page  caching,  and  a  path  setup 
protocol  needs  to  encrypt,  decrypt,  and  validate  packets  at  the  intermediate  nodes  for  safe 
key  distribution. 

These  two  imique  features  of  the  active  network  technologies,  that  routers  axe  pro- 
grammable for  customized  computation  and  new  protocols  axe  easily  deployed,  suit  nicely 
the  development  and  implementation  of  our  proposed  dynamic  path  setup  protocol.  In- 
terdomain  path  setup  not  only  is  an  application  of  active  networks,  it  is  also  an  essential 
tool  for  all  connection-oriented  apphcations  in  active  networks.  There  is  a  strong  synergy 
between  the  two. 

The  active  network  research  group  at  MIT  has  identified  two  approaches  to  an 
active  network  architectiure,  discrete  and  integrated,  depending  on  whether  programs  and 
user  data  are  transported  separately  or  in  an  integrated  fashion  [26,  25].  The  proposed 
dynamic  path  setup  protocol  follows  the  integrated  approach.  To  program  a  network,  the 
integrated  approach  changes  the  passive  packets  of  traditional  network  architectures  to 
active  capsules,  which  are  programs  with  user  data  embedded.  Capsules  are  active  because 
they  are  executed  at  each  router  they  traverse. 
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For  the  deployment  of  active  networks,  the  design  of  active  nodes  axe  extremely 
important.  Since  active  nodes  execute  foreign  codes,  they  need  a  secure  resource  manage- 
ment mechanism  to  protect  themselves  from  possibly  malicious  codes,  as  well  as  to  enforce 
their  own  local  resource  policies.  The  resource  management  mechanism  selectively  allocates 
a  certain  amount  of  resources  to  each  active  capsule  for  a  certain  period  of  time.  If  any 
violation  of  active  capsule  execution  occurs,  the  management  mechanism  should  force  the 
active  capsule  to  terminate. 

There  are  many  issues  and  details  in  the  design  of  active  networks  that  are  beyond 
the  scope  of  this  chapter.  For  its  application  in  communication  path  setup,  we  will  concen- 
trate only  on  the  programming  with  capsules  for  protocol  implementation.  To  implement  a 
path  setup  protocol  in  an  cictive  network,  each  router  should  be  equipped  as  an  active  node. 
Since  the  underlying  active  network  is  a  distributed  computing  engine,  the  determination  of 
a  feasible  routing  path  can  be  decentralized.  That  is,  the  computation  of  a  feasible  routing 
path  can  be  shifted  from  one  node  to  a  set  of  nodes,  and  from  static  to  dynamic.  Thus, 
each  router  no  longer  needs  to  maintain  a  large  routing  information  database  to  keep  track 
of  the  internetwork  topology  as  in  the  Policy  Routing  approach. 

The  encoding  of  capsules  has  yet  to  be  standardized  by  the  active  network  research 

community.  A  functional  description  of  capsules  in  our  dynamic  path  setup  protocol  is 

given  rather  than  detailed  program  codes. 

3.3    Dvnamic  Path  Setup 

The  proposed  dynamic  path  setup  protocol  in  active  networks  uses  active  capsules 
that  contain  control  information  for  iterative  negotiation  of  the  next  routers  from  source 
to  destination  through  some  qualified  intermediate  nodes.  Once  a  path,  which  must  not 
contain  any  routing  loop,  has  been  set  up,  the  protocol  is  also  responsible  for  the  hveness  of 
the  connection  by  providing  a  path  repair  mechanism  for  reconfiguration  of  the  path  upon 
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failures  of  link  or  router.  Before  the  detailed  description  of  the  protocol  in  Sections  3.3.2 

and  3.3.3,  some  data  structures  and  packet  types  used  in  this  protocol  are  described  in  the 

following  subsection. 

3.3.1    Soft  State  and  Packet  Types 

In  active  network  terminology,  a  "soft  state"  for  a  communication  session  specifies 
the  current  status  of  the  session,  and  is  maintained  in  each  paxticipating  node.  For  the 
application  in  dynamic  path  setup,  the  soft  state  consists  of  foiur  data  structures  in  each 
node  of  the  path.  These  data  structures,  listed  below,  either  specify  some  useful  information 
or  record  the  status  of  the  session. 

Security  Association  (SA):  This  association  includes  the  session  ID,  session  key,  encryp- 
tion/decryption algorithms  and  all  other  information  concerning  security. 

Qualified  Neighbor  List  ( QNL):  A  QNL  in  a  node  contains  the  available  neighbors  that  are 
willing  to  provide  the  services  for  the  session. 

Nodes  Traversed  (NT):  An  NT  is  a  sequence  of  nodes  which  have  already  been  traversed 
by  the  Setup  Capsule  (the  Setup  Capsule  is  described  later).  Diuring  path  setup,  the 
Setup  Capsule  carries  an  NT,  which  is  updated  in  each  node.  The  usage  of  NT  in  the 
path  setup  is  to  avoid  a  routing  loop.  After  the  path  has  been  built,  NT  contains  the 
path  and  each  node  should  have  a  copy  of  it. 

Path  Status  (PS):  PS  is  a  two  bit  register  that  keeps  track  of  the  up/down  status  of  the 
previous  and  next  routers  in  the  path. 

Note  that  these  four  data  structures  in  each  node  can  be  uniquely  identified  by  the  session 
ID. 

Packets  in  this  protocol  are  divided  into  two  categories  -  capsule  and  message.  A 
capsule  carries  a  program  for  which  a  receiving  router  will  fork  a  dedicated  process  to 
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execute  the  program.  A  message  only  contains  control  information  that  is  usually  expected 
by  a  waiting  process.  There  are  four  different  capsules  and  eight  diflFerent  messages  used  in 
this  protocol.  All  capsules  and  messages  should  carry  a  session  ID  for  routers  to  identify 
the  session. 

Setup  Capsule:  A  Setup  Capsule  is  generated  from  the  source  host.  It  tries  to  build  a 
routing  path  to  the  destination.  A  Setup  Capsule  contEiins  the  SRS  (source  requested 
service)  and  a  data  structure  NT. 

Repair  Capsule:  A  Repair  Capsule  is  generated  if  a  failed  or  congested  router/link  is  de- 
tected. This  capsule  is  intended  to  find  a  detour  route  to  bypass  the  failed  or  congested 
router/link.  The  Repair  Capsule  contains  the  SRS  and  two  segments  of  the  original 
NT  separated  by  the  failed  or  congested  router/link. 

Auth-Req  Capsule:  An  Auth-Req  Capsule  is  generated  by  the  Setup  Capsule  or  Repair  Cap- 
sule in  each  router  and  broadcasted  to  all  neighbor  nodes  to  collect  the  authorization 
information  about  neighbors.  An  Auth-Req  Capsule  should  contain  the  SRS. 

Data  Capsule:  A  Data  Capsule  carries  the  application  data  and  a  program  for  processing 
the  data. 

Yes/No  Message:  Upon  receiving  the  Auth-Req  Capsule,  each  neighbor  router  checks  its 
local  poUcy.  A  Yes/No  Message  is  sent  back  indicating  whether  the  policy  allows  the 
SRS.  Based  on  these  Yes/No  Messages  from  neighbors,  a  QNL  is  built  and  the  router 
can  choose  the  next  router  to  forward  the  Setup  Capsule  or  Repair  Capsule. 

Grant  Message:  A  Grant  Message  is  generated  from  the  destination  router  if  a  path  is 
found.  It  is  sent  all  the  way  back  to  the  source  through  the  path  just  found.  The  Grant 
Message  carries  the  final  NT  (path)  and  the  security  association.  Upon  receiving  the 
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Grant  Message,  each  router  stores  the  NT  and  the  security  association  in  local  storage 
for  future  use. 

Negative  Message:  A  Negative  Message  is  generated  and  sent  back  to  the  previous  router 
in  NT  if  a  router  could  not  find  any  feasible  neighbor  to  forward  the  Setup  Capsule  or 
Repair  Capsule.  This  occurs  either  when  there  is  no  qualified  neighbor  or  all  qualified 
neighbors  send  back  Negative  Messages. 

Alive  Message:  After  a  path  has  been  established,  each  router  periodically  sends  an  Alive 
Message  to  its  two  adjacent  neighbors  in  the  path  to  assert  its  viability. 

Error  Message:  An  Error  Message  is  generated  if  a  Data  Capsule  violates  the  authenticity 
and  integrity  checks  based  on  the  security  association. 

Repair  Done  Message:  A  Repair  Done  Message  is  generated  if  a  detoiur  path  is  found.  It 
is  sent  back  to  the  failure  detecting  router  through  the  detoiu:  path.  This  message 
carries  the  new  NT  (path)  and  security  association.  Each  router  keeps  the  new  NT 
and  security  association  in  local  storage  for  future  use. 

Tear  Down  Message:  A  Tear  Down  Message  requests  the  routers  to  release  the  memory 
allocated  for  the  session.  If  the  path  can  not  be  repaired,  all  routers  should  receive 
the  Tear  Down  Message.  On  the  other  hand,  if  the  path  is  repaired,  all  routers  not 
in  the  new  path  should  also  receive  the  Tear  Down  Message. 

NT  Update  Message:  This  message  is  to  update  the  NT  stored  in  the  routers  after  a  detour 
path  has  been  built. 

Setup  Capsules,  Auth-Req  Capsules,  Yes/No  Messages,  Grant  Messages,  and  Negative 
Messages  are  used  in  a  path  setup.  After  a  successful  path  setup.  Data  Capsules  are  used 
for  appUcation  data  forwarding,  Alive  and  Error  Messages  are  for  failure  detection,  Repair 
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Capsules  and  Repair  Done  Messages  are  for  detour  route  setup,  and  finally  NT  Update  and 

Tear  Down  Messages  are  for  state  information  consistency.  The  following  two  sections  will 

discuss  the  usages  of  all  the  capsules  and  messages  above  in  detail. 
3.3.2    Path  Setup 

The  network  is  treated  as  a  computing  engine  in  the  ax;tive  network  architecture. 
For  any  network  application,  this  computing  engine  needs  some  input  programs  from  the 
source  host  and  generates  outputs  for  the  application.  In  order  to  build  a  communication 
path,  the  program  should  instruct  the  engine  to  find  a  routing  path  to  the  destination  in 
which  all  participating  routers  are  willing  to  provide  the  requested  service. 

In  the  proposed  path  setup  protocol,  the  input  program  is  a  Setup  Capsule.  The 
soiurce  host  prepares  and  sends  the  Setup  Capsule  to  the  network  engine.  The  Setup  Capsule 
contains  an  empty  NT  at  the  beginning,  and  adds  one  router  each  time  it  traverses  a  router. 
When  a  router  receives  a  Setup  Capsule,  it  proceeds  with  the  following  procedures. 

1.  Routing  Loop  Prevention:  The  router  checks  the  NT  to  see  whether  there  is  a  routing 

loop.  A  routing  loop  exists  if  its  own  ID  is  already  in  the  NT.  In  such  a  case,  a 
Negative  Message  is  sent  back  to  the  previous  router  and  this  process  is  terminated. 

2.  Destination  Router  Process:  The  router  checks  whether  the  destination  host  resides  in 

its  subnet.  If  yes,  the  router  generates  the  security  association  and  sends  it  along 
with  the  NT  to  the  destination  host  and  to  the  previous  router  in  a  Grant  Message. 

3.  Neighbor  Information  Collection:  The  router  broadcasts  an  Auth-Req  Capsule  contain- 

ing the  source  requested  service  to  all  neighbor  routers  and  waits  for  "Yes/No"  re- 
sponses. A  QNL  is  built  for  all  neighbor  routers  responding  with  a  "Yes".  Each 
neighbor  router  executes  the  Auth-Req  Capsule  by  comparing  its  local  pohcy  and 
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the  source  requested  service.  A  "Yes"  Message  is  sent  back  if  the  policy  allows  the 
requested  service.  Otherwise,  a  "No"  Message  is  sent  back. 

4.  Next  Router  Selection  Process:  If  the  QNL  is  not  empty,  this  procedure  adds  the  current 
router  to  NT.  It  selects  one  neighbor  router  from  the  QNL  until  it  is  empty.  For  each 
selected  neighbor  router,  two  steps  are  performed. 

(1)  Forward  the  Setup  Capsule  to  the  selected  neighbor  router. 

(2)  Put  the  Setup  Capsule  Process  into  sleep  and  wait  for  Negative/Grant  Messages. 
If  a  Negative  Message  is  received,  select  another  neighbor  router  and  go  to  step 
(1).  If  a  Grant  Message  is  received,  save  the  security  association  and  NT  in  local 
storage  and  forward  the  Grant  Message  to  the  previous  router  or  to  the  source 
host  if  the  ciurrent  router  is  the  source  router. 

If  all  neighbor  routers  in  QNL  are  selected  and  no  Grant  Message  is  received,  a 
Negative  Message  is  sent  back  to  the  previous  router,  the  current  router  is  deleted 
from  NT,  and  this  process  is  terminated. 

The  Setup  Capsule  generates  the  Auth-Req  Capsule  and  broadcasts  it  to  all  neigh- 
bor routers.  Without  a  careful  design,  this  broadcasting  technique  could  easily  flood  the 
Internet.  The  upper  bound  on  the  number  of  simultaneous  active  capsules  for  this  one  path 
setup  is  the  number  of  neighbor  routers.  The  path  determination  strategy  in  this  protocol 
is  dynamic  because  each  router  decides  the  next  segment  (router)  of  the  path.  The  scenario 
for  this  strategy  is  depicted  in  Figure  3.L  For  a  clearer  overall  view  of  how  this  protocol 
works,  the  execution  flow  chart  for  Setup  Capsule  in  each  router  is  shown  in  Figure  3.2. 
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INTERNET 


Figiire  3.1.  The  scenario  for  dynamic  path  determination 


3.3.3    Path  Repair 

As  described  earlier,  another  dynamic  feature  of  the  protocol  is  to  bypass  a  failed 
or  congested  router/link  during  data  transmission.  In  order  to  achieve  this  functionality, 
another  input  program  for  instructing  routers  to  repair  the  path  must  be  installed  in  each 
router  before  transmitting  the  user  data.  This  path  repair  program  can  be  CEirried  in  the 
Setup  Capsule  or  another  dedicated  capsule.  It  is  activated  in  each  router  when  the  router 
receives  a  Grant  Message,  i.e.,  the  path  is  set.  The  path  repair  program  basically  has  three 
procedures. 

1.  User  Data  Forwarding:  After  a  path  has  been  built,  the  path  repair  program  expects 
Data  Capsules  from  the  source  host.  It  checks  each  capsule's  authenticity  and  integrity 
based  on  the  security  association.  If  the  check  is  successful,  the  data  processing 
program  in  the  Data  Capsule  is  called  and  executed.  The  path  repair  program  resumes 
the  control  and  forwards  the  Data  Capsule  after  the  called  program  is  completed. 
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Figure  3.2.  The  execution  of  Setup  Capsule  in  each  router 


2.  Failed  Router/Link  Detection:  Most  of  the  time,  the  path  repair  program  only  performs 
the  "still  alive  function"  by  sending  and  receiving  Alive  Messages.  It  periodically 
sends  an  Ahve  Message  ecich  to  the  previous  and  next  routers  in  the  path.  A  bit  in 
the  two  bit  register  PS  is  set  if  the  corresponding  router's  Alive  Message  is  received 
within  a  default  time  threshold  T.  If  both  bits  are  set,  PS  is  reset  at  the  end  of  T. 
By  examining  the  PS,  a  router  can  keep  track  of  the  Up/Down  status  of  its  adjacent 
routers  in  the  path. 

Another  potential  failure  is  detected  upon  receiving  an  Error  Message  from  the  next 
router  in  the  path  after  forwarding  a  Data  Capsule  to  it.   Consider  the  situation 
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when  the  next  router  was  down  and  came  up  again  within  the  threshold  T  and  the 
Up/Down  protocol  did  not  detect  the  failure.  The  soft  state  of  this  session  would 
have  been  lost  in  next  router  and  it  could  not  recognize  the  forwarded  Data  Capsule. 
An  Error  Message  would  be  retiu:ned  by  the  next  router. 

3.  Path  Repair:  If  a  failed  router /link  is  detected  by  the  Up/Down  protocol,  the  router 
detecting  the  failure  will  select  another  neighbor  in  QNL  and  send  a  Repair  Capsule 
to  it.  The  scenario  for  issuing  Repair  Capsule  in  this  case  is  shown  in  Figure  3.3. 


NT  Update 


Failure 
Detecting 
Router 


Update 
Reconnecting 
Router 


RT 


Figure  3.3.  The  scenario  for  a  successful  path  repair 


The  Repair  Capsule  is  the  same  as  Setup  Capsule  except  it  finds  a  detoiu:  path 
from  the  failure  detecting  router  to  a  reconnecting  router.  A  recormecting  router  can  be 
any  router  posterior  to  the  failed  router  in  the  original  path.  If  the  failed  router/link  is 
detected  by  receiving  an  Error  Message,  the  Repair  Capsule  is  sent  to  the  next  router  to 
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reconnect  the  path.  In  both  cases,  the  Repair  Capsule  carries  two  segments  of  the  original 
NT.  The  first  segment  of  NT  starts  from  the  source  router  to  the  failure  detecting  router. 
This  segment  of  NT  is  treated  the  same  way  as  the  NT  in  Setup  Capsule,  the  router  ID  is 
inserted  to  the  list  when  the  capsule  travels  through  a  router.  The  second  segment  of  NT 
contains  the  remaining  routers  of  the  original  NT  with  the  failed  router  marked.  It  is  used 
to  determine  whether  a  new  path  has  been  found.  A  new  NT  can  be  computed  from  these 
two  segments  of  NT  when  the  path  repair  is  completed. 

When  a  router  receives  a  Repair  Capsule,  it  compares  its  ID  to  the  two  segments 
of  NT.  There  are  four  possible  results  of  the  comparison. 

(1)  If  its  ID  is  the  marked  router  in  the  original  NT,  the  router  simply  rebuilds  the  soft 
state  to  reconnect  the  path  for  the  session  and  sends  a  Repair  Done  message  back  to 
the  failure  detecting  router. 

(2)  If  its  ID  appears  in  the  first  segment  of  NT,  a  routing  loop  exists  and  a  Negative 
Message  is  sent  back  to  the  previous  router  in  the  first  segment  of  NT. 

(3)  If  its  ID  appears  in  the  second  segment  of  NT,  the  router  is  a  reconnecting  router  and 
a  detour  path  has  been  found.  The  sequence  of  routers  posterior  to  the  reconnecting 
router  in  the  second  segment  of  NT  is  appended  to  the  first  segment  of  NT  to  form 
a  new  NT  for  the  new  path.  Then,  a  Repair  Done  Message  containing  the  new  NT 
is  sent  back  to  the  failure  detecting  router  through  the  new  path.  All  routers  in  the 
new  path  need  to  update  their  state  information  by  receiving  either  the  Repair  Done 
Message  or  NT  Update  Message.  Also,  all  routers  in  the  old  path  but  not  in  the  new 
path  need  to  be  released  by  receiving  the  Tear  Down  Message.  More  detailed  usages 
of  NT  Update  and  Tear  Down  Messages  will  be  discussed  later  in  this  section. 

(4)  If  its  ID  does  not  appear  in  either  of  the  two  segments  of  NT,  the  same  procedure  for 
the  Setup  Capsule  is  applied  to  the  Repair  Capsule.  That  is,  the  router  broadcasts 
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the  Auth-Req  Capsule,  builds  the  QNL,  selects  a  router  from  QNL,  and  forwaxds  the 
Repair  Capsule  to  the  selected  router. 

The  execution  flow  chart  for  Repair  Capsule  in  a  router  is  shown  in  Figure  3.4. 
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Figiue  3.4.  The  execution  of  Repair  Capsule  in  each  router 


For  a  successful  path  repair,  the  consistency  of  the  soft  state  NTs  among  all  routers 
in  the  new  path  should  be  maintained  as  follows. 


37 


(1)  Upon  receiving  the  Repair  Done  Message,  the  failure  detecting  router  issues  an  NT 
Update  Message  containing  the  new  NT  to  all  prior  routers  in  the  new  path. 

(2)  After  sending  a  Repair  Done  Message,  the  reconnecting  router  should  issue  an  NT 
Update  Message  containing  the  new  NT  to  all  posterior  routers  in  the  new  path  and 
a  Tear  Down  Message  to  all  prior  routers  in  the  second  segment  of  NT. 

In  the  Up/Down  protocol,  two  routers  may  detect  a  failed  router/link  simultane- 
ously. Only  the  one  closer  the  source  issues  the  Repair  Capsule.  The  one  closer  the  destina- 
tion should  expect  a  Repair  Capsule  or  a  Tear  Down  Message  for  a  default  time  threshold 
T'.  If  nothing  is  received  within  T',  it  means  that  the  path  repair  is  not  successful  and  a 
Tear  Down  Message  is  issued  to  the  routers  posterior  to  it  in  the  path. 

If  the  failure  detecting  router  receives  a  Negative  Message,  it  means  that  the  path 
repair  is  not  successful.  The  router  should  try  to  send  another  Repair  Capsule  to  another 
neighbor  router  in  its  QNL  until  the  QNL  is  empty.  If  all  neighbor  routers  are  tried  and 
not  one  is  successful,  the  correct  action  is  to  either  send  a  Tear  Down  Message  all  the  way 
ba£k  to  the  source  or  send  a  Negative  Message  back  to  the  previous  router  in  the  NT.  The 
first  choice  stops  seajching  another  path  and  informs  the  soiurce  that  there  is  no  existing 
path  at  this  moment.  The  second  choice  continues  to  search  another  detour  path  starting 
from  the  previous  router  in  the  NT.  Which  choice  to  select  should  depend  on  the  upper 
layer  applications. 

The  purpose  of  Tear  Down  Messages  is  to  release  the  resources  in  the  routers  which 
are  no  longer  serving  for  the  session.  In  case  of  these  routers  do  not  receive  the  Tear  Down 
Message  because  of  another  failure,  the  resomrce  management  mechanism  in  each  active 
node  should  handle  this  after  the  life  time  of  the  session  being  expired.  The  execution  flow 
chart  for  the  path  repair  program  in  a  router  is  shown  in  Figiure  3.5. 
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Figure  3.5.  The  execution  of  path  repair  program  in  each  router 


In  this  protocol,  there  are  three  major  programs  running  in  each  participating 
routers.  These  programs  are  the  Setup  Capsule,  path  repair  program,  and  Repair  Cap- 
sule. Table  3.1  briefly  summcirizes  the  diff'erences  among  them. 

3.4    Chapter  Summary 

A  dynamic  interdomain  path  setup  protocol  is  presented  in  this  Chapter.  We  assume 
that  the  underlying  network  architecture  is  the  active  network,  a  novel  network  architecture 
in  which  each  intermediate  network  node  is  able  to  perform  some  customized  computation. 
The  protocol  is  different  from  others  in  that  it  utilizes  a  distributed  path  determination 
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Table  3.1.  Comparison  among  Setup  Capsule,  path  repair  program,  and  Repair  Capsule 
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strategy  and  has  an  automatic  path  repair.  The  distributed  path  determination  strategy 
shifts  the  decision  from  the  source  router  to  all  intermediate  routers. 

We  believe  that  the  philosophy  behind  the  strategy  fits  more  precisely  in  the  con- 
text of  interdomain  communication,  i.e.,  the  one  providing  the  service  makes  the  decision. 
Furthermore,  the  automatic  path  repair  mechanism  can  detect  failures  much  quicker  since 
they  are  always  discovered  first  by  the  nearest  router.  The  nearest  router  can  initiate  the 
path  repair  process  immediately  upon  detecting  a  failure.  An  active  network  environment 
facilitates  both  the  computational  and  communication  aspects  of  the  protocol.  Many  active 
network  applications  will  rely  on  such  a  connection  setup  protocol  to  estabhsh  active  nodes 
for  their  respective  computation. 

Whether  and  how  to  reconfigure  a  communication  path  upon  failures  is  an  important 
protocol  design  issue.  To  repair  a  failed  communication  session,  a  fast  path  repair  process 
is  crucial.  The  process  should  be  efiicient  in  failure  detection  and  recovery.  The  proposed 
protocol  achieves  fast  failure  detection.  However,  failure  recovery  requires  a  fast  detour 
path  setup  and  relies  on  a  good  QNL  selection  criteria.  Each  router  in  the  path  setup 
protocol  has  no  knowledge  of  the  QNL  in  the  selected  next  router.  If  the  QNL  is  empty,  a 
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Negative  Message  may  be  returned  and  cause  a  rewinding  of  the  search.  This  kind  of  path 
setup  rewinding  should  be  limited  by  use  of  good  selection  criteria.  One  way  to  decrease  the 
possibility  of  path  setup  rewinding  is  to  increase  the  information  available  to  each  router, 
for  example,  the  past  history  of  previous  path  setup  or  QNL  of  the  neighbors.  To  make 
this  information  available  to  each  router  may  slow  down  the  path  setup  in  another  respect. 
Therefore,  future  work  on  this  protocol  should  include  finding  good  QNL  selection  criteria. 

Multiple  failiue  is  another  issue  not  addressed  in  the  protocol.  There  may  be 
multiple  routers  detecting  different  failures  more  or  less  simultaneously.  It  is  not  a  good 
idea  to  have  multiple  path  repair  processes  running  at  the  same  time.  Simultaneous  repairs 
may  result  in  redundant  work  and  even  incorrect  path  repair  due  to  interference.  This  is 
also  an  open  area  to  be  addressed. 


CHAPTER  4 

KEY  ASSIGNMENT  FOR  ACCESS  CONTROL  POLICY  EXCEPTIONS 

In  the  previous  two  chapters,  two  static  and  one  dynamic  interdomain  access  control 
protocols  are  discussed.  All  of  them  intend  to  build  a  secure  communication  path,  though 
their  approaches  aire  different.  There  is  a  preliminary  requirement  for  building  a  secure 
path,  i.e.,  safe  session  key  distribution.  In  Chapter  2,  we  assume  that  a  symmetric  key 
encryption  algorithm  is  used  for  this  purpose.  Therefore,  every  policy  gateway  should 
share  a  secret  key  with  each  host  within  its  domain  and  every  two  adjacent  (neighbor) 
policy  gateways  also  should  share  a  secret  key.  For  policy  gateways  in  a  big  domain  or  in 
a  topological  critical  location,  the  burden  of  managing  hundreds  (even  thousands)  of  keys 
may  affect  their  performance. 

In  this  chapter,  a  cryptographic  key  assignment  scheme  is  proposed  that  can  be 

used  to  assign  keys  to  internetwork  domains  for  safe  session  key  distribution.  Instead  of 

remembering  hundreds  of  keys,  each  domain  gateway  only  needs  to  remember  two  keys. 

We  concentrate  the  discussion  on  the  key  assignment  scheme  itself  in  this  chapter.  How  to 

apply  the  scheme  to  interdomain  access  control  will  be  addressed  in  Chapter  5. 

4.1  Background 

If  system  users  are  divided  into  distinct  groups  or  classes,  C  =  {Ci,  C2, . . . ,  Cn}, 
each  class  should  have  an  encryption  key  to  protect  data  owned  by  the  users  in  this  class. 
Each  class  in  the  system  would  have  a  different  clearance  and,  consequently,  a  different 
accessible  set.  In  such  a  system,  the  accessible  set  of  a  class  Q  is  the  set  of  classes  whose 
encrypted  data  can  be  decrypted  by  Q.  An  access  control  policy  of  a  system  defines  the 
accessible  sets  of  all  classes.  The  objective  of  this  chapter  is  to  design  a  key  assignment 
scheme  so  that  the  access  control  pohcy  can  be  enforced. 
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The  most  straightforward  implementation  of  this  problem  requires  classes  to  memo- 
rize all  encryption  keys  of  their  accessible  sets.  This  approach  scales  poorly.  Akl  and  Taylor 
first  proposed  an  elegant  key  assignment  scheme  [1]  to  overcome  this  dilemma,  but  their 
scheme  only  enforces  policies  in  a  hierarchical  structure.  An  access  control  policy  expressed 
in  a  hierarchy  defines  the  set  C  as  a  partially  ordered  set  (poset)  on  an  accessible  relation. 
We  will  describe  the  properties  of  a  poset  in  Section  4.2  and  their  key  assignment  scheme  in 
Section  4.5.1.  There  are  many  papers  [15,  22,  9,  8,  23,  14,  11,  33,  27,  31,  30,  28]  that  address 
key  assignment  for  access  control  in  a  hierarchy  (poset)  structure.  However,  in  practice, 
some  systems  may  need  more  complex  access  control  policies  that  can  not  be  expressed 
in  a  hierarchy.  These  complex  access  control  policies  may  violate  the  antisymmetric  and 
transitive  properties  of  posets. 

For  example,  suppose  a  system  contains  raw  data  owned  by  a  class  C3  that  should 
remain  secret  from  ordinary  users  in  a  class  Ci .  A  special  class  C2  exists  of  users  who  can 
preprocess  the  raw  data  and  translate  the  data  into  another  form  before  presenting  them 
to  class  C\  users.  Namely,  C\  can  access  C2  and  C2  can  access  C3,  but  C\  cannot  access 
C3.  This  transitive  exception  policy  is  very  common  and  important  for  real  systems. 

Moreover,  the  antisymmetric  property  of  posets  forces  all  classes  in  an  accessible 
cycle  to  be  equivalent,  placing  too  many  restrictions  on  a  system's  group/class  partition. 
In  Section  4.3,  a  distributed  static  database  example  is  provided  to  show  the  importance  of 
transitive  and  antisymmetric  exceptions  in  real  practice.  Therefore,  a  poUcy  model  based 
on  a  hierarchy  structiure  with  exceptions,  and  a  new  key  assignment  scheme  are  proposed. 
These  will  enforce  access  control  policies  in  which  antisymmetric  and  transitive  excep- 
tions are  included,  in  addition  to  the  policies  with  partial  ordered  set  (poset)  properties. 
Compared  to  schemes  for  hierarchies,  the  cost  to  achieve  our  more  powerful  scheme  for 
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hierarchies  with  exceptions  is  one  more  key  for  each  user  class  to  memorize  or  one  more 
step  to  access  its  own  data. 

This  chapter  is  organized  as  follows:  Section  4.2  presents  the  access  control  poli- 
cies that  can  be  handled  in  the  hierarchy  structure  and  in  the  hierarchy  structiure  with 
exceptions.  Section  4.3  provides  an  interesting  distributed  static  database  example  whose 
access  control  policy  has  antisymmetric  and  transitive  exceptions.  Section  4.4  discusses 
the  related  works  with  respect  to  several  criteria.  All  of  the  existing  schemes  assume  the 
hierarchy  structure.  Section  4.5  gives  a  brief  description  of  Akl  ajid  Taylor's  scheme.  Sec- 
tion 4.6  describes  the  new  cryptographic  key  assignment  in  a  hierarchical  structiure  with 

exceptions.  Finally,  Section  4.7  summarizes  this  chapter. 

4.2    Access  Control  Policies 

An  access  control  policy  for  a  system  specifies  rules  that  regulate  the  information 
flow  between  difierent  user  classes  in  the  system.  In  this  section,  we  show  that  access 
control  pohcies  in  the  hierarchical  structure  with  exceptions  are  a  superset  of  those  in  the 
hierarchy.  To  describe  the  access  control  policies  in  both  structures,  first  some  definitions 
are  necessary. 

Definition  4.2.1  An  n-system  is  a  system  with  n  distinct  user  classes  C  =  {Ci,  C2, . . . ,  C„}. 

Definition  4.2.2  Three  properties  must  hold  for  an  n-system  to  be  a  poset  on  a  relation 
R: 

1.  Reflexive  property:  QRCi,  where  Ci  €  C. 

2.  Antisymmetric  property:  dRCj  and  CjRd  ^Ci  =  Cj,  where  d  and  Cj  6  C. 

3.  Transitive  property:  dRCj  and  CjRCk     CiRCk,  where  d,  Cj  and  Ck  G  C. 
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Definition  4.2.3  An  accessible  set  of  a  class  Ci  in  an  n-system  is  the  set  ASi  =  {Cj  G  C 
:  Ci  can  access  Cj}. 

Definition  4.2.4  A  dominating  set  of  a  class  Ci  in  an  n-system  is  the  set  DSi  =  {Cj  G 
C  :  Cj  can  access  Ci}  =  {Cj  E  C  :  Ci  E  ASj}. 

Definition  4.2.5  An  access  control  policy  of  an  n-system  is  the  collection  of  all  accessible 
sets  {ASi,AS2,...,ASn}. 

A  hierarchical  structure  for  an  n-system  preserves  the  three  properties  of  posets  on 
the  accessible  relation.  Thus,  any  access  control  policy  {ASi,AS2,  ■■• ,  ASn}  in  a  hierarchy 
has  following  properties:  For  i,  j,k  =  1,2, ...  ,n 

1.  Cj  6  ASi  (reflexive  property) 

2.  If  Cj  G  ASi  and  Cj  G  ASj  =i>-  Ci  =  Cj  (antisymmetric  property) 

3.  If  Cj  G  ASi  and  Ck  G  ASj  =^  Ck  e  ASi  (transitive  property) 

On  the  other  hand,  any  access  control  policy  in  the  hierarchy  structure  with  exceptions  for 
an  n-system  only  needs  to  satisfy  two  properties: 

1.  Ci  G  ASi  (reflexive  property) 

2.  If  ASi  =  ASj  and  DSi  =  DSj  =^Ci  =  Cj.  (equivalence  property) 

The  combination  of  reflexive  and  antisymmetric  properties  in  the  hierarchy  structure  also 
implies  the  equivalence  property. 

Proposition  4.2.1  If  an  access  control  policy  has  the  reflexive  and  antisymmetric  proper- 
ties, then  it  also  has  the  equivalence  property. 
Proof: 

Assume  that  an  access  control  pohcy  P  does  not  have  the  equivalence  property.  That  is, 
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3i,j  such  that  ASi  =  ASj  and  DSi  =  DSj,  but  Q  ^  Cj. 

By  the  assumed  reflexive  property,  Cj  G  ASi  and  Cj  6  ASj^  so  we  have  Cj  G  ^45,  and 
Cj  G        but  Cj  ^  Cj.  Thus,  P  does  not  have  the  antisymmetric  property. 

Any  hierarchical  access  control  policy  satisfies  reflexive,  antisymmetric,  and  transitive  prop- 
erties. By  Proposition  4.2.1,  this  access  control  policy  also  satisfies  reflexive  and  equivalence 
properties  and  must  belong  to  the  hierarchy  structmre  with  exceptions.  Therefore,  the  set 
of  hierarchical  access  control  policies  with  exceptions  is  a  superset  of  the  set  of  hierajchical 
access  control  policies. 

Both  the  antisymmetric  and  equivalence  properties  are  rules  to  decide  the  equiv- 
alence of  two  classes.  In  terms  of  the  conditions  for  equivalence  testing,  the  equivalence 
property  is  more  relaxed  than  the  antisymmetric  property.  This  relaxation  is  because  the 
absence  of  transitivity  in  the  hierarchy  structure  with  exceptions  makes  possible  different 
accessible  and  dominating  sets  for  two  classes,  though  they  can  access  each  other.  The  re- 
laxation gives  a  system  the  opportunity  to  have  a  more  flexible  class/group  partition,  i.e., 
two  classes  that  can  access  each  other  no  longer  need  to  be  equivalent.  This  antisymmetric 
exception  is  extremely  useful  for  a  system  handling  indirect  remote  accesses  in  a  distributed 
environment. 

In  order  to  get  a  clearer  view  of  these  two  policy  structures,  a  directed  graph  (DG) 
representation  of  access  control  policies  in  both  structures  is  discussed  below.  A  node  in 
a  DG  represents  a  class  in  a  system.  Two  kinds  of  edges,  positive  and  negative  edges,  are 
used  in  the  DG.  The  positive  edges  indicate  that  the  source  nodes  are  allowed  to  access 
the  destination  nodes,  but  the  negative  edges  indicate  that  the  accesses  are  prohibited.  If 
there  is  a  conflict  between  these  two  kinds  of  edges,  negative  edges  take  precedence.  The 
other  difference  between  them  is  that  positive  edges  have  transitive  property  but  negative 
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edges  do  not.  That  is,  a  node  A  can  access  another  node  B  if  there  exists  a  positive  path 
(sequence  of  positive  edges)  from  Aio  B.  Whereas  the  negative  path  (sequence  of  negative 
edges)  from  A  io  B  does  not  mean  A  cannot  access  B  if  the  path  length  is  greater  than 
one.  Basically  there  are  two  conditions  to  decide  the  accessibility  for  node  A  to  node  B. 

Condition  1:  If  there  exists  a  positive  path  (a  sequence  of  positive  edges)  from  Aio  B. 
Condition  2:  If  there  exists  a  negative  edge  from  Aio  B. 

If  Condition  1  is  true,  but  not  Condition  2,  then  A  can  access  B.  On  the  other  hand,  if 
Condition  1  is  false  or  Condition  2  is  true,  then  A  can  not  access  B.  Having  this  kind  of 
DO  in  mind,  it  is  possible  to  discuss  the  policy  structures.  For  the  hierarchy  structure,  the 
DGs  must  obey  the  three  properties  of  posets. 

1.  Reflexive  Property:  Each  node  should  have  a  positive  edge  to  itself.  It  means  each  class 

can  access  its  own  data. 

2.  Transitive  Property:  A  node  can  access  another  node  if  there  exists  a  positive  path  to 

that  node. 

3.  Antisymmetric  Property:  Two  nodes  are  equivalent  if  both  of  them  have  a  positive  path 

to  the  other.  In  general,  a  positive  path  cycle  in  a  DC  means  all  nodes  in  this  cycle 
can  access  each  other  and  should  be  the  same  class.  Thus,  for  an  n-system,  the  n 
node  DC  must  be  acyclic. 

Obviously,  the  negative  edges  do  not  exist  in  hierarchies,  since  their  purpose  is  to  kill 
the  transitive  property  selectively.  They  are  used  only  in  the  hierarchy  structure  with 
exceptions.  For  the  hierarchy  structure  with  exceptions,  the  DGs  have  two  properties. 

1.  Reflexive  Property:  Each  node  should  have  a  positive  edge  to  itself. 

2.  Equivalence  Property:  Two  nodes  are  equivalent  if  both  of  them  have  a  positive  path  to 

the  other  and  the  same  immediate  predecessors  and  successors  for  the  negative  edges. 
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Two  access  control  policy  examples  that  can  be  handled  in  the  hierarchy  structure 
with  exceptions,  but  not  in  the  hierarchy  structm-e  are  given  in  Figure  4.1  and  Figure  4.2. 
For  clsirity,  self-pointing  edges  for  the  reflexive  property  in  the  DG  policy  representation 
are  omitted  for  rest  of  the  chapter. 


class 

accessible  set 

dominating  set 

Ci 

Ci ,  C2 

Ci 

Ci 

C2,  C3 

Ci ,  C2 

C3 

C3 

C2,  C3 

Figure  4.1.  A  policy  in  a  3-system  that  only  violates  the  transitive  property 


class      accessible  set    dominating  set 

jCi  Ci ,  C2  ,C3  Ci ,  C3  

C2  C2 ,  C3  Ci ,  C2  

C3        I    C1.C3  I    Cl,C2,C3  ~ 

Figure  4.2.  A  poUcy  in  a  3-system  that  violates  the  antisymmetric  and  transitive  properties 

In  Figure  4.2,  there  is  a  positive  cycle  Ci  C2  ->  C3  ->  Ci.  These  three  classes 
are  not  equivalent  in  the  hierarchy  structure  with  exceptions  because  ASi  ^  ASj  and 
DSi  ^  DSj  for  i  ^  j  and  1  <  z,  j  <  3.  Two  transitive  exceptions  also  exist  in  this  example. 
One  is  C2  C3  and  C3  Ci,  but  C2  A  Ci.  The  other  is  C3  ^  Ci  and  Ci  C2,  but 
C3  -A  C2.  These  two  transitive  exceptions  allow  difierent  accessible  sets  and  dominating 
sets  for  these  three  classes.  Therefore,  an  access  control  pohcy  with  the  antisymmetric 
exceptions  should  also  have  transitive  exceptions. 

An  access  control  pohcy  {ASi,AS2, ASn}  of  an  n-system  can  be  represented  as 
an  n  X  n  matrix  A,  where 
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^  ^  I  1   if  CjEASi 
'■^     1  0  otherwise 

For  example,  the  access  control  policy  in  Figure  4.2  can  be  represented  as  Table  4.1.  This 
Table  4.1.  Matrix  A  -  a.  policy  in  a  3-system 


Ci 

C2 

1 

1 

1 

0 

1 

1 

Cs 

1 

0 

1 

matrix  A  is  diflferent  from  the  access  control  matrix  (ACM)  of  HRU  model  [10].  The  ACM 
is  a  matrix  correlating  the  subject,  object  and  the  authorizations  owned  by  each  subject 
on  each  object.  The  rows  of  ACM  correspond  to  subjects  and  the  columns  to  the  objects. 
Each  element  ACM[i,j]  contains  the  access  modes  for  which  the  subject  i  is  authorized 
on  object  j.  However,  the  matrix  used  here  merges  subjects  and  objects  with  the  same 
security  level  into  a  class.  Both  the  rows  and  columns  of  the  matrix  A  correspond  to  the 
classes.  The  element  Aij  of  matrix  A  denotes  the  access  authorization  between  classes  d 
and  Cj.  Aij  =  1  indicates  that  the  class  Cj  has  the  privilege  to  access  the  class  Cj;  A^j  =  0 
otherwise. 

4J  Policv  Exception  Example:  A  Distributed  Static  Database  Svstem 

Consider  a  static  database  that  contains  some  tables  with  confidential  records.  Users 
can  only  make  a  request  to  a  specific  query  processor  to  retrieve  information  in  these  tables. 
Table  4.2  EMPLOYEE  gives  an  example  of  confidential  records  in  a  static  database  system. 
A  user  in  this  system  can  not  directly  access  the  confidential  records.  Instead  he  or  she  can 
make  requests  such  as  "How  many  employees  are  ranked  1  ?"  or  "How  many  employees 
have  salaries  of  $60,000  or  higher  ?"  to  the  query  processor.  The  query  processor  goes  over 
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Table  4.2.  Confidential  records  for  EMPLOYEE 


Name 

Rank 

Sex 

Age 

Salary 

Joe 

1 

M 

50 

60,000 

Sam 

2 

M 

45 

55,000 

Mary 

1 

F 

46 

62,000 

John 

3 

M 

36 

50,000 

the  EMPLOYEE  table  and  answers  the  user:  "There  are  two  employees  are  ranked  1"  and 
"There  are  two  employees  with  salaries  60,000  or  higher". 

In  this  context,  there  are  three  classes:  Ci  for  users,  C2  for  the  query  processor, 
and  C3  for  the  EMPLOYEE  table.  The  EMPLOYEE  table  is  encrypted  to  prevent  direct 
access  from  Ci.  C\  maJces  a  request  to  C2,  and  C2  derives  the  encryption  key  of  C3  to 
decrypt  the  EMPLOYEE  table.  C2  sends  the  answer  encrypted  by  its  own  encryption  key 
to  C\.  Then  C\  decrypts  it  and  gets  the  answer.  A  transitive  exception  exists  among 
these  three  classes.  That  is,  Ci  can  access  C2,  C2  can  access  C3,  but  Ci  cannot  access  C3. 
Encryption  of  the  answer  is  necessary  whenever  there  are  several  classes  of  users  and  each 
user  class  only  can  retrieve  the  static  information  over  some  confidential  tables  through  a 
diff'erent  query  processor.  For  simplicity,  we  assume  there  is  only  one  user  class  and  one 
query  processor. 

Next,  the  example  is  extended  to  a  distributed  environment  to  show  that  the  anti- 
symmetric exception  is  also  important.  Suppose  a  company  has  distributed  sites  connected 
by  a  network.  Each  site  has  its  own  confidential  tables  and  three  classes  as  above.  A  user 
who  wants  remote  access  to  the  static  information  from  another  site  is  not  allowed  to  make 
requests  directly  to  the  remote  query  processor.  The  request  must  go  to  the  local  query 
processor  first,  which  decides  whether  to  forward  the  request  to  the  remote  query  processor. 
If  the  request  is  forwarded,  the  remote  query  processor  prepares  and  encrypts  the  answer 
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and  sends  it  back  to  the  local  query  processor.  The  local  query  processor  first  decrypts  the 
answer,  then  re-encrypts  the  answer  so  that  the  user  can  decrypt  it.  The  two-site  example 
is  depicted  in  Figure  4.3  (Eight  negative  edges  representing  the  transitive  exceptions  are 
omitted  here  for  clarity).  The  corresponding  access  control  poUcy  for  this  example  is  shown 
in  Table  4.3. 


Site  A 


C 1 :  users 


Cj:  query  process 


C3:  confidential 
tables 


Site  B 


C4 :  users 


C5:  query  process) 


Ce:  confidential 
tables 

Figure  4.3.  A  two-site  distributed  static  database  system 


Table  4.3.  Matrix  A  -  the  access  control  policy  for  a  two-site  distributed  static  database 
system 


Ci 

C2 

Cz 

C4 

C5 

1 

1 

0 

0 

0 

0 

C2 

0 

1 

1 

0 

1 

0 

C3 

0 

0 

1 

0 

0 

0 

C4 

0 

0 

0 

1 

1 

0 

C5 

0 

1 

0 

0 

1 

1 

0 

0 

0 

0 

0 

1 
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In  this  example,  both  query  processors  in  sites  A  and  B  can  access  each  other, 

but  they  are  not  equivalent.  There  are  eight  transitive  exceptions  and  one  antisymmetric 

exception  in  this  example.  We  will  show  that  this  example  can  be  handled  by  our  key 

assignment  scheme  in  Section  4.6,  but  not  by  other  schemes  in  the  Uterature. 

4.4    Related  Work 

The  cryptographic  key  assignment  problem  for  a  system  to  enforce  the  access  control 
poUcy  was  first  investigated  by  Akl  and  Taylor  [1].  They  proposed  an  elegant  solution  to 
enforce  access  policies  modeled  as  a  partial  order  set.  Their  scheme  is  simple  with  respect  to 
the  key  generation  and  derivation  procedures,  but  suflFers  high  memory  overhead,  weak  ap- 
pendabiUty  and  restricted  (hierarchy-based)  set  of  policies.  Appendability  weakness  means 
that  the  keys  for  existing  classes  need  to  be  recomputed  when  a  new  security  class  is  added. 
For  a  decade,  research  on  this  key  assignment  problem  concentrated  on  finding  solutions  to 
reduce  memory  overhead  and  increase  appendability.  As  the  computer  technology  is  evolv- 
ing toward  distributed  computing,  the  hierarchy  policy  structure  becomes  too  restricted  to 
model  the  needs  for  distributed  systems.  This  chapter  intends  to  develop  a  key  assignment 
scheme  that  can  enforce  a  richer  set  of  policies  for  distributed  systems. 

Mackinnon  et  al.  [15]  presented  an  improved  scheme  using  canonical  assignment 
to  reduce  memory  overhead.  Hajn  and  Lin  [9]  proposed  another  scheme  in  which  the  key 
assignment  is  handled  by  a  bottom-up  approach,  while  [1]  and  [15]  are  top-down  approaches. 
AppendabiUty  weakness  is  addressed  by  Sandhu  [22],  Harn,  Chien  and  Kiesler  [8],  Liaw  [14], 
Hwang  et  al.  [11],  Wu  et  al.  [33],  Tsai  et  al.  [27].  This  appendability  problem  is  difficult 
to  solve  and  no  existing  scheme  heis  achieved  complete  appendability.  Some  solutions  to 
reduce  the  complexity  are  to  limit  the  access  control  policy  to  a  tree  structure,  which  is 
a  special  case  of  the  hierarchy  structure.  Others  reduce  the  recomputation  to  a  smaller 
set  of  existing  keys  with  different  degrees  of  compensation.  In  [22],  an  ID-based  scheme 
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is  presented  by  iteratively  applying  one-way  functions  to  solve  the  problem  only  for  tree 
like  structures.  Harn,  Chien,  and  Kiesler  [8]  presented  a  scheme  that  divides  a  system  into 
several  subgroups  to  reduce  the  affected  keys  while  a  new  class  is  added.  Each  subgroup 
has  a  root  class  responsible  for  replying  to  a  request  from  higher  subgroup.  Liaw's  [14] 
scheme,  which  is  based  on  the  RSA  [20]  public  key  system  increases  appendabiUty,  but  it 
still  suffers  from  key  recomputation  overhead  when  the  added  class  has  a  high  security  level. 
Hwang  et  al  [11]  presented  a  scheme  in  which  the  addition/deletion  of  a  class  needs  only 
to  modify  the  keys  of  immediate  higher  classes.  In  their  scheme,  a  class  with  r  immediate 
lower  classes  must  assign  a  unique  integer  from  1  to  r  to  each  immediate  lower  classes.  In 
order  to  derive  the  immediate  lower  classes'  keys,  each  class  needs  to  memorize  the  integer 
identifiers  of  them.  The  scheme  of  Wu  et  al  [33]  is  based  on  the  Chinese  remainder  theorem 
and  it  achieves  the  appendability  without  changing  other  existing  keys,  but  a  set  of  pubUc 
parameters  needs  to  be  modified.  Tsai  et  al  [27]  proposed  a  scheme  based  on  Rabin's  public 
key  system  and  the  concept  of  the  Chinese  Remainder  theorem  and  Newton's  interpolating 
method.  Their  scheme  still  needs  to  update  the  secret  interpolating  polynomials  of  those 
seciuity  classes  that  have  access  privileges  on  a  new  class,  though  no  existing  keys  need  to 
be  modified. 

The  other  criterion  to  evaluate  a  scheme  is  the  efficiency  of  key  derivation.  Some 
schemes  [1],  [15],  [9],  [14],  [33],  [27]  derive  a  subordinate  key  directly,  but  others  [22], 
[8],  [11]  need  iterative  derivation. 

Although  the  new  scheme  proposed  in  this  chapter  has  the  same  advantages  and 
disadvantages  as  in  [1],  a  new  and  important  capabiUty  for  oiur  scheme  that  broadens  access 
control  from  the  hierarchical  structure  to  the  hierarchy  structure  with  exceptions  is  never 
addressed  before. 
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4.5    Akl  and  Taylor's  Kev  Assignment  Scheme 
4.5.1    Key  Assignment  and  Derivation 

In  Akl  and  Taylor's  key  assignment  scheme,  there  is  a  central  authority  Co-  In  an 
n-system,  Co  must  generate  a  set  of  encryption  keys  Ki,K2,...,Kn  and  send  Ki  to  each 
class  d  securely.  Each  class  Ci  can  use  its  own  key  Ki  and  some  public  information  Tj  and 
Tj  to  derive  the  class  Cj  's  key  Kj  if  Q  is  allowed  to  access  Cj.  Cq  proceeds  the  following 
steps. 

1.  Generate  a  secret  number  Kq. 

2.  Compute  the  product  M  of  two  large  prime  numbers  and  make  it  public. 
For  i,j  =  l,2,...,n 

3.  Assign  a  distinct  prime  number  Pi  for  each  class  Ci. 

4-  Compute  pubUc  information  Tj  =  n/i<j=o  ^ji  where  matrix  A  is  defined  in  Section  4.2. 

5.  Assign  each  Ki  =  Kq'  mod  M. 

The  class  C,-  uses  the  key  derivation  function, 

f{Ki,Ti,Tj)  =  Kf'^'^'  mod  M, 

to  derive  Cj 's  key  Kj,  where 

Kj  =  kI^  =  [Kffil'^'  =  i^p/^'  mod  M. 

The  derivation  function  f{Ki,  Tj,  Tj)  is  feasible  to  compute  if  and  only  if  Tj  jTi  is  an  integer 
(see  proof  in  next  section).  This  statement  relies  on  the  belief  [20]  that  computing  r-th 
roots  (mod  M)  for  integral  r  >  1  is  as  diflScult  as  factoring  M.  Their  scheme  assigns  all 
public  information  T's  in  such  a  way  that  TjjTi  is  an  integer  if  and  only  if  the  policy  allows 
Ci  to  access  Cj. 
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For  example,  the  policy  of  a  5-system  in  Table  4.4  (the  corresponding  DG  policy 
representation  in  Figure  4.4)  can  be  enforced  by  assigning  keys: 

Ki  =  Kq  mod  M 
K2  =      mod  M 
Kz  =  Kl^  '^  mod  M 
K4  =  K^-^-^  mod  M 
=  Kl^-^  ''  mod  M. 

Note  that  there  are  no  transitive  or  antisymmetric  exceptions  in  this  example.  Their  scheme 
can  only  enforce  policies  in  the  hierarchy. 

Table  4.4.  Akl  and  Taylor's  scheme  for  a  policy  in  a  5-system 


Ci 

C2 

C3 

C4 

C5 

Pi 

Ti 

Ci 

1 

1 

1 

1 

2 

1 

C2 

0 

1 

1 

1 

3 

2 

C3 

0 

0 

1 

0 

5 

2-3-7 

0 

0 

0 

1 

7 

2-3-5 

C5 

0 

0 

0 

0 

11 

2-3-5-7 

© 


Figure  4.4.  DG  representation  of  a  policy  in  a  5-system 
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4.5.2    Correctness  of  the  Akl  and  Taylor's  Scheme 

A  correct  key  assignment  scheme  should  prohibit  all  illegal  key  derivations.  There 
are  two  kinds  of  illegal  key  derivations  in  the  hierarchy  structure: 

1.  A  class  Ci  derives  a  class  Cj 's  key,  but  the  policy  forbids  d  from  accessing  Cj. 

2.  A  set  of  classes  H  C  C  coUusively  derive  a  class  Cj 's  key,  but  the  policy  does  not 
allow  any  class  in  H  to  access  Cj. 

In  Akl  and  Taylor's  paper,  they  give  a  theorem  (below)  and  several  propositions  (4.5.1, 
4.5.4,  4.5.5,  and  4.5.6)  to  show  the  correctness  of  their  scheme.  We  add  two  propositions 
(4.5.2  and  4.5.3)  here  that  make  the  proof  of  correctness  more  complete.  (The  notation 
Ti  I  Tj  below  means  that  Tj  is  a  factor  of  T,  and  T,  /f  T,  otherwise). 

Theorem  [1]  Let  t  and  <i , . . . ,  be  given  integers  and  suppose  there  is  a  feasibly  computable 
function  G  for  which 

=  G{K^',K*\...,K^"){modM) 

for  every  K  in  Z^,  the  group  of  units  mod  M.  Let 

d  =  gcd{ti],  e  =  gcd{t,  d},  and  r  =  d/e. 

Then  we  can  feasibly  compute  r-th  roots  in  Z^. 
Proof: 

TaJcing  any  H  in  Z^,  we  will  compute  H^I^{modM).  Let  K  =  H^l^  (we  cannot  necessary 
compute  K)  and  r,-  =  ti/d.  Choose  a  and  b  so  that  e  —  at  +  bd.  Then 

=  H''G{K'^'-',...,K'^'-"Y 
=  H''G(H^i,...,/f")"(modM), 
and  this  can  feasibly  be  computed. 
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The  argument  relies  on  the  current  beUef  [20,  pp.  126]  that  computing  r-th  roots 
(mod  M)  for  integral  r  >  1  is  as  difficult  as  factoring  M.  The  case  r  =  2  is  proved 
in  [17].  The  method  therein  generalizes  to  the  case  r  j  $(M),  where  $(M)  is  the  Euler 
totient  function.  In  Akl  and  Taylor's  paper,  Proposition  4.5.1  only  has  the  "only  if  part. 

T-  IT- 

Because  the  value  Tj/Tj  can  be  very  large,  the  function  f  =  K^"  '  mod  M  is  not  feasible 
to  compute.  In  order  to  make  the  "if  part  of  this  proposition  also  true,  we  assume  that 
there  exists  an  upper  boimd  U  for  the  value  Tj /Ti  so  that  /  is  feasible  to  compute. 

Proposition  4.5.1  The  key  derivation  function  f{Ki,Ti,Tj)  is  feasible  to  compute  iffTi  j 
Tj. 

Proof: 

If  f{Ki,Ti,Tj)  is  feasible  to  compute  =^  Kj  =  {{KQ)-^j){modM)  is  feasible  to  compute 
from  Ki  for  every  Kq. 

By  the  Theorem  above,  r  =  1  and  hence  Tj  |  Tj.  Otherwise  we  could  compute  nontrivial 
roots  in  Z^. 

Proposition  4.5.2  Kj  can  be  derived  from  Ki  iff  f{Ki,Ti,Tj)  =  {Ki)'^i^'^'  =  Kj  is  feasible 

to  compute. 

Proof: 

If  f{Ki,Ti,Tj)  is  feasible  to  compute,  then  it  is  obvious  that  Kj  can  be  derived  from  Ki. 
Conversely,  if  f{Ki,Ti,Tj)  =  [Ki^ilTi  =  Kj  is  infeasible  to  compute  =>  Tj/Ti  is  not  an 
integer,  (by  Proposition  4.5.1) 

Suppose  that  Kj  can  be  derived  from  Ki  by  using  other  pubhc  information  X  and  Y  so 
that  f{Ki,X,Y)  =  Kj  is  feasible  to  compute  ^  Y/X  is  an  integer,  (by  Proposition  4.5.1) 
Since  f{Ki,X,Y)  =  {{Kof^)^/^  =  Kj  ^  Ti  ■  Y/X  =  Tj      Y/X  =  Tj/Ti  -  contradiction. 
Thus  Kj  cannot  be  derived  from  Ki. 
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Proposition  4.5.3  Kj  can  be  derived  from  Ki  iff  Ti  \  Tj 
Proof: 

By  Propositions  4.5.1  and  4.5.2,  the  result  follows. 

Proposition  4.5.4  Under  the  assignment  scheme  in  Section  4-5.1,  Ti  \  Tj  iff  Aij  =  1. 
Proof: 

If  Aij  =  1  =^  Cj  e  ASi.  For  any  Ck  e  ASj,  we  have  Ck  G  ASi  (transitive  property) 
^  ASj  C  ASi. 

Since  Ti  =  0^,^=0  A  =  Uc^AS,  Pk,  Tj  =  nAj,=oPk  =  Uc.USj  P",  and  ASj  C  ASi  =^ 
Ti  I  Tj. 

Conversely  if  Ay  =O^Pj\Ti.  Since  Ajj  =  1  (reflexive  property)  ^  Pj  J(Tj     Ti  J(Tj. 

Proposition  4.5.5  Under  the  assignment  scheme  in  Section  4.5.1,  a  key  Kj  can  be  feasibly 
computed  from  a  set  of  keys  {Ki  :  Q  E  H}  iff  gcd{Ti  :  d  E  H)  \  Tj,  where  H  CC. 
Proof: 

If  g  =  gcd(Ti  :  Ci  E  H),  then  we  can  choose  integers  such  that  g  =  "^jj  aiTi.  If  Tj  =  gm 
for  some  integer  m,  then  Kj  =  {Kofi  =  (Ko)*""  =  WHiKof'"'"^  =  YlHiKi)"'"'  and  Kj 
can  be  computed  from  Ki 's. 

Conversely,  if  there  exists  a  feasibly  computable  function  for  obtaining  Kj  =  {Ko)^i  {mod 
M)  from  the  Ki's  for  every  Kq.  By  the  Theorem  above,  r  =  1  and  gcd(rj  :  Ci  E  H)  \  Tj. 

Proposition  4.5.6  Under  the  assignment  scheme  in  Section  4.5.1,  a  set  of  classes  H  C  C 

can  not  collusively  derive  a  class  Cj,'s  key  if  Aij  =  0  for  all  Ti  E  H. 

Proof: 

Pj  I  Ti  whenever  Aij  =  0,  therefore,  Pj  \  gcd(Tt  :  Aij  =  0). 

But  Ajj  =  1  (reflexive  property)  =^  {Pj  j{Tj)     gcd(Ti  :  Aij  =  0)  J(Tj. 
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By  Proposition  4.5.5,  the  result  follows. 

Prom  Propositions  4.5.3  and  4.5.4,  Kj  can  be  derived  from  Ki  if  and  only  if  the  policy  allows 

Ci  to  access  Cj.  Thus,  the  first  illegal  key  derivation  is  prohibited.  Prom  Propositions  4.5.5 

and  4.5.6,  the  second  illegal  key  derivation  is  also  prohibited. 

4.6    The  New  Kev  Assignment  Scheme 

The  new  key  assignment  scheme  basically  follows  the  same  approach  as  Akl  and 
Taylor's  scheme.  One  of  the  differences  is  that  there  are  two  keys  {K^  and  K^)  assigned 
to  each  class:  for  data  encryption  and  for  key  derivation.  If  a  class  Ci  would  like 
to  access  data  of  a  class  Cj ,  Ci  uses  its  own  derivation  key  Kf  and  some  public  informa- 
tion to  derive  Cj's  encryption  key  Kj.  The  purpose  of  assigning  two  keys  for  each  class 
is  to  enforce  transitive  exception  policies.  For  example,  a  transitive  exception  policy  for  a 
3-system  {Ci,C2,C3}  defines  that  Ci  can  access  C2  and  C2  can  access  C3,  but  Ci  cannot 
access  C3  as  in  Figure  4.5.  If  only  one  key  is  assigned  to  each  class,  there  is  no  way  to 
enforce  the  transitive  exception  because  Ci  can  always  derive  C3 's  key  by  deriving  C2 's  key 
first.  With  two  keys  for  each  class  in  our  assignment  scheme,  this  problem  can  be  solved. 
The  idea  of  enforcing  transitive  exceptions  in  the  assignment  scheme  is  shown  in  Figure  4.5 
(here,  an  arrow  in  the  key  derivation  rule  means  the  source  key  can  derive  the  destination 
key).  Furthermore,  two  keys  for  each  class  also  make  it  possible  to  enforce  antisymmetric 
exceptions.  Therefore,  two  classes  can  access  each  other's  information  without  being  equiv- 
alent. Figure  4.6  shows  the  key  derivation  rule  for  enforcing  antisymmetric  exceptions.  The 
key  assignment  scheme  proposed  in  this  section  assigns  keys  in  a  way  that  follows  the  key 
derivation  rules  so  that  the  transitive  and  antisymmetric  exceptions  can  be  enforced. 
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Figure  4.6.  A  3-system  with  an  antisymmetric  exception  and  the  corresponding  key  deriva- 
tion rule 

4.6.1    Key  Assignment  and  Derivation 

The  access  control  policy  in  a  matrix  A,  described  in  Section  4.2,  only  indicates 
which  class  can  access  another.  Transitive  exception  information  is  embedded  in  A.  There- 
fore, an  algorithm  is  necessary  to  translate  the  matrix  A  into  another  n  x  n  matrix  UM 
that  indicates  explicitly  the  transitive  exception  information,  where 
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1 


if  Aij  =  1 


UMij  =  < 


— 1  i{3  ki,3  k2,. .  ■  ,^  kn, 
such  that  1  <ki  <n, 
for  all  i,  1  <  m  <  n  —  2, 

and  Aij  =  0.  (transitive  exception) 
0  otherwise 


The  transformation  algorithm  computes  the  transitive  closure  A*  of  A  and  compares 
A*  and  A  to  find  out  the  transitive  exceptions  so  that  the  matrix  U M  can  be  constructed. 

Algorithm  6.1  Transformation  from  A  to  UM  using  A*  =  transitive  closure  {A) 
UM  =  A-{A*  -A)  =  2A-  A*. 

We  demonstrate  the  transformation  of  algorithm  6.1  with  the  distributed  static  database 
example  in  Table  4.3.  Table  4.5  is  the  resulting  matrix  UM.  With  the  transformed  matrix 

Table  4.5.  Matrix  UM  -a.  policy  in  a  6-system  with  explicit  transitive  exception  information 


Ci 

C2 

C4 

Ci 

1 

1 

-1 

0 

-1 

-1 

0 

1 

1 

0 

1 

-1 

Cz 

0 

0 

1 

0 

0 

0 

0 

-1 

-1 

1 

1 

-1 

0 

1 

-1 

0 

1 

1 

Ce 

0 

0 

0 

0 

0 

1 

C/M,  the  central  authority  Co  proceeds  as  followings. 

1.  Generate  a  secret  number  Kq. 

2.  Compute  the  product  M  of  two  large  prime  numbers  and  make  it  public. 
For  i,  j,  A;  =  1,2, . . .  ,n 
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3.  Assign  a  distinct  prime  number  Pj  to  each  row  UMiolUM  and  Pj/  to  each  row  UMi 
of  UM  where 


another  distinct  prime  number   if  3  j  such  that  UMij  =  —  1 

otherwise 


^.  Compute  the  pubhc  information 


Tt={  n  Po)-Pi' 


UMij=0 


Tt=i  n  pj)-(  n  Pk') 

UMij=0  UMki=l 


5.  Assign  keys 


Kf  =  {Kofi  mod  M 
Kf  =  {Kofi  mod  M 
to  each  class  Cj  and  send  them  securely. 

The  class  Cj  can  use  the  key  derivation  function 

f{Kf,Tf,T^)  =  {KffV^t  mod  M 

to  derive  the  encryption  key  K^  of  Cj,  where 

if?  =  {Kof^  mod  M 

=  {{Koftfil'^t  ^odM 
=  {KffV'^t  mod  M 

The  way  to  assign  public  information  T's  in  step  2  ensures  that  TJ/T/  is  an  integer  if 
and  only  if  the  policy  allows  Ci  to  access  Cj.  The  key  derivation  function  f{Kf,Tf,T^) 
is  feasible  to  compute  if  and  only  if  T^/Tf  is  an  integer  (Proposition  4.5.1).  Therefore, 
Ci  can  access  Cj 's  data  by  deriving  Cj 's  encryption  key  using  the  key  derivation  function 
f{Kf,Tf,T?). 
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For  the  access  control  policy  in  Table  4.5,  Figure  4.7  shows  the  corresponding  key 
derivation  rule  and  Table  4.6  illustrates  a  possible  assignment  of  the  prime  numbers  and 
public  information.  The  key  assignments  using  the  new  scheme  are: 

Kf  =         mod  M 

=  K^  '^  '^^  mod  M 
Ki  =  i(:2-3-7.iM3  mo^i 

Kf  =  K^^^  mod  M 
Ki  =  K^  '^-^^  mod  M 
Ki  =  K^^-^  '^-^^  mod  M 


Figure  4.7.  The  key  derivation  rule  for  the  poUcy  in  Table  4.5 
4.6.2    Correctness  of  the  Proposed  Scheme 

There  are  three  possible  illegal  key  derivations  in  the  hierarchy  structure  with  ex- 
ceptions: 

1.  A  class  Ca  derives  class  Cb's  keys,  but  the  policy  does  not  allow  Ca  to  access  Cf,. 


K{  =  Kl^''  mod  M 

K^  =  X2.7.17.19.29 

KI  =  ii:2-3-7.1113.19  M 

KI  =  K^-^^  mod  M 

KI  =  i(:2-7.l9.23.29  ^ 

KI  =  Kl^-^''-^^-^^modM 
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Table  4.6.  Prime  numbers  and  public  information  for  the  policy  in  Table  4.5 


Pi 

Pif 

rpd 

■'■i 

2 

17 

7-17 

7-17 

3 

19 

2-7-19 

2-71719-29 

Cs 

5 

1 

2-3-71M3 

2-3-7-1M3- 
19 

7 

23 

2-23 

2-23 

11 

29 

2-7-29 

2-719-23-29 

Ce 

13 

1 

2-3-5-7-11 

2-3-5-711- 
29 

2.  A  class  Ca  derives  class  Cc 's  keys  by  iteratively  deriving  another  classes  C^j 's,  Ci,^  's, 
. . . ,  C(,m  keys,  where  the  policy  allows  Ca  to  Jiccess  Cftj ,  Ctj  to  access  C^j,  . . . ,  Cj,„ 
to  access  Cc,  but  not  Ca  to  access  Cc- 

3.  A  set  of  classes  H  C  C  coUusively  derive  class  Ca 's  keys,  but  the  poUcy  does  not 
allow  any  class  in  H  to  access  Ca- 

We  use  indices  a,b,c  6  {1, 2, ... ,  n}  along  with  k  €  {1, 2, . . . ,  n}  (used  in  assignment 
definitions  in  Section  4.6.1)  to  avoid  confusion.  The  proposed  key  assignment  scheme  is 
correct  and  the  above  three  illegal  key  derivations  are  infeasible.  Lemmas  4.6.6,  4.6.7 
and  4.6.8  (below)  prove  the  first,  second,  and  third  illegal  key  derivations  respectively  are 
infeasible. 

First,  we  give  a  proposition  showing  the  key  derivation  relationship  between  keys. 

Proposition  4.6.1  Under  the  key  assignment  scheme  in  Section  4-6.1,  if  a  key  can 
derive  a  key  Kf  (for  x  =  d  or  e),  then  (i)  any  key  can  be  derived  from  K^,  it  also  can  be 
derived  from  K^;  (ii)  any  key  can  derive  K^,  it  also  can  derive  K^. 
Proof: 

(i)  Let  a  set  of  keys  A  =  {K^  :      can  be  derived  from  KD  and  a  set  of  keys  B  =  {K^  : 


64 


can  be  derived  from  K^}- 

By  Proposition  4.5.3,  we  can  rewrite  A  =  {K^  :      \  T^}  and  B  =  {K^  :      \  T^}. 
Since      can  derive      =^      \      (by  Proposition  4.5.3)  ^ADB. 
(ii)  Let  a  set  of  keys  A  =  {K^  :       can  derive  K^]  and  a  set  of  keys  B  =  {K^  :  can 
derive  K^}- 

By  Proposition  4.5.3,  we  can  rewrite  A  =  {K^  :      |  T^}  and  B  =  {K^  :      \  T^}. 
Since       can  derive  |      (by  Proposition  4.5.3)  =^ACB. 

In  the  key  assignment  scheme  in  Section  4.6.1,  each  class  can  use  its  own  derivation  key  to 
derive  its  own  encryption  key.  Because  of  this  property,  each  class  only  needs  to  memorize 
a  derivation  key,  but  one  more  key  derivation  would  be  necessary  whenever  it  wants  to 
access  its  own  data.  The  Proposition  4.6.2  shows  this  property. 

Proposition  4.6.2  Under  the  key  assignment  scheme  in  Section  4-6-1,        can  always 

derive  K^. 

Proof: 

By  Proposition  4.5.3,  we  only  need  to  show      |      is  always  true. 


cn 


Pk') 


The  last  inference  step  is  because  UMaa  = 


1  is  always  true  at  index  k  =  a. 


Therefore,  T^/T^  is  always  an  integer  and  we  have  the  result. 


Proposition  4.6.3  Under  the  key  assignment  scheme  in  Section  4. 6.1,  (i)  if  a  key  can  be 
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derived  from  K^,  it  also  can  be  derived  from  K^;  (ii)if  a  key  can  derive  K^,  it  also  can 

derive  K^. 

Proof: 

By  Propositions  4.6.1  and  4.6.2,  the  result  follows. 

Proposition  4.6.4  If  U Mat  =  1,  then  UMaj  =  0  implies  UMbj  —  0. 
Proof: 

Case  1:  Let  UMab  =  1,  UMaj  =  0,  and  UMbj  =  1. 

UMab  =  1  and  UMbj  —  1  =^  UMaj  =  1  if  Aaj  =  1  (transitivity),  or  UMaj  =  —  1  if  Aaj  =  0 

(transitive  exception). 

Thus,  U Maj  ^  0  -  contradiction. 

Case  2:  Let  UMab  =  1,  UMaj  =  0,  and  UMbj  =  -1. 

UMbj  =  3KuK2,  ...,Km  such  that  Abk^  =  Ak.k^  =  ■■■  =  Ak„j  =  1  but  Abj  =  0. 

UMaj  =0=^  Aaj  =  0. 

UMab  =  1      Aab  =  1  ^  Aab  =  Abki  =  ^fcifcj  =  •  •  •  =  Ak^j  =  1  but  Aaj  =  0  (transitive 
exception)  =>  UMaj  =  —  1- 
Thus,  U Maj  7^  0  -  contradiction. 

Since  UM^^y  G  {-1,0, 1}  and  UMbj  #  -1,  UMbj  ¥^  h  so  UMbj  =  0 

Proposition  4,6.5  Under  the  key  assignment  scheme  in  Section  4.6.1,  \  T§  iff  UMab  - 
1. 

Proof: 

By  Proposition  4.6.4,  if  UMab  =  1, 

then  {UMaj  =  0  =J>  UMbj  -  0). 

inus,  jT — — —  =  I,  where  /  is  a  positive  integer. 
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Pal 


The  last  inference  step  is  because  UMab  =  1  is  true  at  index  k  =  a. 
Thus,  Ti  I  T^. 

Conversely,  if  UMab  ^  1      either  (1)  UMab  =  0  or  (2)  f/Mot  =  -1. 

(1)  Since      =  {Uum.j^o  Pj)  ■  Pa'- 
If  UMab  =  0=^Pb\T^ 

since  UMbb  =  1  and 

T§  =  {UuM,j^oPj)iUuM,,^lPk') 

SoPbJ(T§, 
Thus,  J(T,\ 

(2)  If  UMab  =  -l^Paf\      and  Pj  ¥^  I. 
But  Paf  JiT§, 

Thus,  T<f/T,^ 

Lemma  4.6.6  If  the  policy  does  not  allow  Ca  to  access  Cb,  then  it  is  infeasible  for  Ca  to 

derive  Cb's  keys  under  the  key  assignment  scheme  in  Section  4-6.1. 

Proof: 

The  available  information  for  Ca  are  K^,  K^,  and  all  public  information  Tf,  and  Tf  for  all 
i. 

By  Proposition  4.5.2,  only  four  possible  inputs  {K^,  T^,  T^),  {K^,  T^,  T§),  {K^  T^),  and 
{K^,Ta,T^)  to  function  /  need  to  be  considered. 

By  Proposition  4.6.3,  we  only  need  to  show  one  input  {K^,  T^,  T§)  to  /  is  not  feasible  to 
compute. 
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Since  Ca  is  not  allowed  to  access  Cfc  ^  J(T§  (by  Proposition  4.6.5)  f{K^,T^,T§)  is 
not  feasible  to  compute,  (by  Proposition  4.5.1) 

If  an  access  control  policy  of  a  system  contains  transitive  exceptions,  the  possibility  of  the 
second  illegal  key  derivation  becomes  a  threat.  Fortunately,  our  key  assignment  scheme  is 
immune  from  this  threat. 

Lemma  4.6.7  //  the  policy  does  not  allow  Ca  to  access  Cc,  but  Ca  can  access  C\,^,  Cbi  can 
access  C^j,  . . . ,  Cb^  can  access  Cc  for  1  <  m  <  n—2,  then  it  is  infeasible  for  Ca  to  iteratively 
derive  Cc's  keys  by  deriving  Cbi  's,  Cb2  's,  . . . ,  Cb„  's  keys  under  the  key  assignment  scheme 
in  Section  4-6.1. 
Proof: 

Basically  we  want  to  show  that  there  does  not  exist  any  key  derivation  chain  from  to 
ioT  X  =  d  or  e. 

Suppose  there  exists  a  key  derivation  chain  — >^  K^^  — >  K^^  K^^  -¥  K^. 

Since       can  derive  K^^  and  K^^  can  derive  K^^  ^       can  derive        (by  Proposition 

4.6.1) 

By  applying  Proposition  4.6.1  m  times,  we  have  the  result  that       can  derive  K^. 
It  is  a  contradiction. 

Thus,  there  does  not  exist  any  key  derivation  chain  from      to  K^. 

Finally,  lemma  4.6.8  shows  our  key  assignment  scheme  is  infeasible  for  the  collusive  attack. 
That  is,  a  set  of  malicious  classes  combines  their  information  to  derive  a  key  that  the  policy 
does  not  allow  them  to  derive. 

Lemma  4.6.8  //  the  policy  does  not  allow  any  class  in  a  set  of  classes  H  C  C  to  access  Ca, 
then  it  is  infeasible  for  classes  in  H  to  collusively  derive  Ca 's  keys  under  the  key  assignment 
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scheme  in  Section  4-6.1. 
Proof: 

By  Proposition  4.6.3,  we  only  need  to  show  a  set  of  derivation  keys  {K^  :  Cb  E  H}  can  not 

coUusively  derive  Ca's  encryption  key  K^,  where  UMba  ^  1. 

If  UMba  =  0,  3Pa  I  T^;  or  if  UMba  =  -1,  3Pbf  I      where  Pfe/  7^  1. 

Therefore,  Pa  \  gcd{T^  :  UMba  =  0);  or  Pbf  |  gcd{T^  :  UMba  =  -1)  where  Pft/  ^  1. 

But,  Pa  /     is  always  true,  and  Pfc/  J(T^  if  UMba  =  -1- 

Thus,  gcd(T^  ^  1)  /T«. 

By  Proposition  4.5.5,  we  have  the  result. 

We  have  proved  correctness  of  the  proposed  key  assignment  scheme  by  showing 
that  the  three  possible  illegal  key  derivations,  listed  at  the  beginning  of  the  section,  are  not 
feasible. 

4.7    Chapter  Summary 

This  Chapter  gives  a  cryptographic  key  assignment  scheme  for  controlMng  access  to 
data  in  an  organization  where  the  access  control  policy  for  this  organization  can  be  any 
pohcy  in  the  hierarchy  structiure  with  exceptions.  This  structure  can  model  not  only  the 
access  control  policies  in  the  hierarchy,  but  also  more  complex  poUcies  that  have  antisym- 
metric or  transitive  exceptions.  Transitive  exceptions  usually  occiu-  in  a  system  that  is 
not  hierarchy-based.  Both  antisymmetric  and  transitive  exceptions  are  quite  conmion  for  a 
distributed  system  as  the  example  shown  in  Section  4.3.  The  cost  of  this  new  cryptographic 
key  assignment  scheme,  compared  to  the  Akl  and  Taylor's  scheme,  is  one  more  key  for  each 
class  to  memorize  or  one  more  step  to  access  its  own  data. 

There  are  two  keys  (derivation  and  encryption  keys)  assigned  to  each  class  in  our 
cryptographic  key  assignment  scheme.  The  encryption  key  for  a  user  class  is  used  to  encrypt 
data  to  protect  against  illegal  access  from  other  user  classes.  The  derivation  key  for  a  user 
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class  is  used  to  derive  the  encryption  keys  of  other  user  classes  in  order  to  decrypt  and 
access  their  data.  The  key  assignment  scheme  assures  that  a  class'  derivation  key  cannot 
derive  a  class'  encryption  key  in  violation  of  the  policy. 


CHAPTER  5 

INTERDOMAIN  SAFE  SESSION  KEY  DISTRIBUTION 

In  this  chapter,  we  will  address  how  to  apply  the  proposed  key  assignment  scheme 
to  internetwork  domain  key  distribution. 

First,  we  need  to  know  the  topology  of  the  current  Internet  and  Section  5.1  gives 
the  brief  overview.  Second,  Section  5.2  discusses  how  to  transfer  the  Internet  topology  to  a 
directed  graph  (DG)  defined  in  Chapter  4  which  represents  the  internetwork  domain  access 
control  policy.  Before  performing  the  transformation,  it  is  necessary  to  argue  the  reasonable 
assumption  about  access  privileges  among  domains  in  the  ciurrent  Internet.  Section  5.3 
demonstrates  how  to  use  the  assigned  keys  to  distribute  the  session  key.  Finally,  a  simuuary 
is  given  in  Section  5.4. 

5.1    Current  Internet  Topology 

The  current  Internet  is  basically  a  hierarchical  structure  with  exceptions  [6].  It  is 
composed  of  many  different  stub  domains  and  transit  domains.  Stub  domains  like  govern- 
ment, university,  and  private  companies  carry  only  network  traffic  to  and  from  end  systems 
within  their  own  domain.  While  transit  domains  like  MAN,  LAN,  WAN  carry  network 
traffic  to  and  from  other  domains. 

The  links  between  WANs  form  a  global  transit  backbone  of  the  Internet.  The  links 
among  stubs,  LANs  and  WANs,  together  with  the  transit  backbone,  make  the  Internet  as 
a  connected  graph  so  that  any  host  in  any  domain  can  communicate  with  another  host 
in  another  domain.  This  basically  forms  the  hierarchical  structure  of  Internet.  However, 
at  times  during  its  development  the  Internet  topology  appeared  to  have  some  exceptions. 
Some  stub  domains  may  want  to  build  lateral  links  because  of  easy  exchange  of  information. 
For  example,  a  lateral  hnk  between  two  universities  is  for  research  purpose  or  between  two 
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companies  is  for  cooperated  business.  The  lateral  links  could  occur  at  any  level  of  hierarchy 
(e.g.,  direct  Unks  between  WAN's,  between  LAN's,  and  between  stubs).  Another  exception 
also  exists  when  some  stub  domains  not  only  have  a  link  to  a  LAN,  but  also  have  a  bypass 
link  to  a  WAN.  Figmre  5.1  shows  the  structure  of  the  ciurrent  Internet. 


^^^^        LAN    hierarchy  link 

O  STUB    lateral  link 

Figure  5.1.  The  Internet  topology 

5.2    Internet  Topologv  and  Directed  Graph  Mapping 

This  Section  tries  to  map  the  Internet  topology  to  a  DG  defined  in  Chapter  4.  Each 
domain  in  Figure  5.1  is  mapped  as  a  node  (class)  in  the  DG  and  each  link  in  Figmre  5.1  is 
mapped  as  one  or  two  positive  edges.  It  is  a  straightforward  one-to-one  mapping  between 
domains  and  nodes.  The  mapping  between  links  and  positive  edges  needs  to  consider  the 
following  two  cases. 
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1.  Either  a  hierarchy  or  a  bypass  Unk  is  mapped  as  a  positive  edge  with  arrow  pointing 
to  the  lower  level  node. 

2.  A  lateral  link  is  mapped  as  two  positive  edges  pointing  to  different  directions. 

The  first  case  means  higher  level  domains  can  derive  lower  level  domains'  secret  keys. 
Since  a  lower  level  domain  requires  a  higher  level  domain's  transit  service  and  packets 
originating  from  the  lower  level  domain  are  usually  protected  by  its  secret  key.  Therefore, 
it  is  necessary  to  grant  higher  level  domains  the  privilege  to  derive  lower  level  domains' 
secret  keys.  The  second  case  occurs  at  the  same  level  and  two  positive  edges  means  that 
both  domains  can  derive  the  other's  secret  key.  This  assumption  is  reasonable  because 
a  lateral  hnk  connects  two  domains  requiring  each  domain  to  provide  transit  service  (for 
transit  domains)  or  process  data  (for  stub  domains)  for  the  other.  The  mapping  discussed 
so  far  only  includes  the  positive  edges,  Figure  5.2  shows  the  DG  mapping  from  the  Internet 
topology  in  Figure  5.1.  In  the  lateral  link  mapping,  we  use  one  double-arrow  edge  instead 
of  two  positive  edges  for  clarity. 


Figure  5.2.  The  DG  with  only  positive  edges 
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The  mapping  from  a  lateral  link  to  a  double-arrow  edge  forms  access  cycle  between 
two  domains.  In  the  definition  of  DG  in  Chapter  4,  these  two  domains  should  be  treated 
as  the  same  class.  This  is  bad  because  these  two  domains  are  actually  under  different 
administrative  authority.  Fortunately,  some  negative  edges  can  be  added  to  make  them 
different,  though  they  can  access  each  other. 

In  figure  5.2,  WAN  1  can  derive  all  secret  keys  of  its  subtree  of  the  hierarchy  (i,e., 
LAN  1,  STUB  1,  and  STUB  2).  Likewise,  WAN  2  can  derive  the  secret  keys  of  LAN  2, 
STUB  3,  STUB  4,  and  STUB  5.  If  there  is  a  double-arrow  edge  between  WAN  1  and  WAN 
2,  this  means  that  both  WANl  and  WAN  2  can  derive  the  secret  keys  of  the  other's  subtree. 
If  WAN  1  (or  WAN  2)  is  compromised,  all  communications  among  domeiins  within  WAN 
2's  (or  WAN  I's)  subtree  could  be  compromised.  This  is  not  desirable  because  it  violates 
the  "need  to  know"  (a  form  of  least  privilege)  security  principle.  Therefore,  it  is  better  not 
to  give  a  domain  the  access  privilege  beyond  the  lateral  link.  Negative  edges  can  be  used 
to  break  the  transitive  property  of  the  double  arrow  edges  so  that  a  domain  can  not  access 
beyond  the  lateral  links. 

In  Chapter  4,  a  negative  edge  connecting  two  classes  only  indicates  that  the  source 
class  can  not  derive  the  destination  class'  key.  It  is  a  "one-to-one"  relationship  between 
classes,  i,e.,  a  specific  source  class  to  a  specific  destination  class.  In  the  application  of 
internetwork  domain  discussed  above,  a  class  may  not  have  the  privilege  to  access  a  set 
of  classes.  For  example,  WAN  2  should  not  access  LAN  1,  STUB  1,  and  STUB  2.  If  we 
use  the  negative  edge  defined  in  Chapter  4,  three  negative  edges,  which  point  from  WAN 
2  to  LAN  1,  STUB  1  and  STUB  2  respectively,  are  necessary  to  represent  the  transitive 
exceptions.  For  the  DG  representation  clarity  of  Internet  domain  access  control  policy,  we 
redefine  the  negative  edge  to  be  an  edge  pointing  from  a  source  node  to  a  virtual  destination 
node.  The  virtual  destination  node  represents  the  set  of  nodes  that  should  not  be  accessed 
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by  the  soiirce  node.  Figure  5.3  shows  the  DG  with  negative  edges  pointing  to  virtual  nodes 
using  the  same  Internet  topology  example. 


Figure  5.3.  The  DG  with  negative  edges  and  virtual  nodes 


This  kind  of  DG  greatly  reduces  the  number  of  negative  edges  needed  to  represent 
the  access  pohcy  of  the  internetwork  domain  application.  In  the  example  above,  only  7 
negative  edges  are  needed,  though  there  are  32  transitive  exceptions. 

Having  an  Internet  domain  access  control  policy  like  the  one  shown  in  Figure  5.3, 
a  new  key  generation  scheme  can  be  used  to  assign  keys  to  each  domain  for  secure  session 
key  distribution.  The  scheme  to  distribute  the  session  key  is  addressed  in  next  section. 
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5.3    Safe  Session  Kev  Distribution 

After  the  secret  keys  are  assigned  to  each  domain,  the  session  key  for  any  commu- 
nication session  can  be  safely  distributed.  We  use  an  example  in  Figiure  5.2  to  demonstrate 
the  distribution  of  a  session  key.  A  source  host  in  STUB  2  wants  to  communicate  with 
a  destination  host  in  STUB  5.  The  path  setup  initiates  from  STUB  2,  and  goes  through 
LAN  1,  WAN  1,  WAN  2,  WAN  3,  then  STUB  5.  If  all  stub  and  transit  domains  allow 
communication  between  the  source  and  destination  hosts,  STUB  5  generates  a  session  key 
and  distributes  it  to  all  domains  in  the  path.  Figure  5.4  illustrates  the  scenario  of  session 
key  distribution. 


Figiure  5.4.   Packet  A  contains  <  Kg  >k^  ,    which  means  that  the  session  key  K.  is 

stub  5  t/  o 

encrypted  by  the  assigned  encryption  key  K^t^^  5  of  stub  5;  and  Packet  B  and  C  contain 
<      >^S,a„  ,^d<Ks  >Ki,^^  ^  respectively 

First,  STUB  5  uses  its  assigned  encryption  key  to  encrypt  the  session  key  and 
forwards  it  to  WAN  3  in  packet  A.  WAN  3  is  capable  of  deriving  STUB  4's  encryption  key 
and  decrypting  the  session  key.  After  getting  the  session  key,  WAN  3  should  use  its  own 
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encryption  key  to  re-encrypt  the  session  key  in  packet  B  and  forward  it  to  WAN  2.  Upon 
receiving  packet  B  from  WAN  3,  WAN  2  derives  WAN  3's  encryption  key  to  decrypt  the 
session  key.  At  this  point,  there  are  two  possible  access  control  assumptions: 

1.  WAN  1  is  able  to  derive  WAN  3's  encryption  key.  A  communication  path  could  contain 
a  long  list  of  consecutive  WANs.  If  WANs  cannot  access  across  lateral  links  among 
WANs,  the  session  key  re-encryption  occurs  at  each  WAN  and  slows  down  the  com- 
munication. 

2.  WAN  1  is  not  able  to  derive  WAN  3's  encryption  key.  This  assumption  sacrifices 
performance  to  achieve  better  security. 

In  Figiure  5.4,  we  use  the  first  assumption  and  WAN  2  just  forwards  packet  B  to  WAN 
1.  There  is  no  re-encryption  necessary  for  WAN  2.  In  the  first  assumption,  WAN  1  is 
able  to  derive  WAN  3's  encryption  key  and  decrypt  the  session  key.  Instead  of  using  its 
own  encryption  key,  WAN  1  derives  STUB  I's  encryption  key  to  encrypt  the  session  key  in 
packet  C  and  forwards  the  packet  to  LAN  1.  LAN  1  derives  STUB  I's  encryption  key  to 
decrypt  the  session  key  and  forwards  packet  C  to  STUB  1.  Finally,  STUB  1  uses  its  own 
encryption  key  to  decrypt  the  session  key.  Of  course,  the  packet  header  should  contain  a 
node  ID  field  indicating  who  encrypts  the  session  key  so  that  the  receiving  nodes  is  able  to 
derive  the  corresponding  encryption  key. 

We  assume  no  preference  for  either  assumption,  though  the  example  above  uses  the 
first  one  for  demonstration.  Which  assumption  should  be  used  depends  on  whether  security 
or  performance  is  more  important  to  the  Internet  communication. 

In  Chapter  2,  we  list  two  kinds  of  lAC  protocols  -  KIAC  and  TIAC.  Example  above 
is  based  on  the  KIAC  protocol.  For  the  TIAC  protocol,  the  key  distribution  process  is 
similar  except  that  each  domain  gateway  puts  the  session  key  into  the  ticket  instead  of 
storing  it  in  local  memory.  The  number  of  session  key  encryptions  in  KIAC  is  equal  to  the 
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number  of  ticket  layers  in  TIAC.  In  the  example  of  Figure  5.4,  the  session  key  encryptions 
occurred  at  STUB  5,  WAN  3  and  WAN  1.  Thus,  three  layers  are  necessary  in  the  ticket 
for  the  TIAC  protocol. 

5.4    Chapter  Summary 

In  this  chapter,  we  demonstrate  how  to  use  the  key  assignment  scheme  for  safe 
session  key  distribution,  as  well  as  the  mapping  from  Internet  topology  to  interdomain 
access  DG.  The  assumption  of  access  privileges  for  an  internetwork  domain  in  Section  5.2 
requires  further  detailed  discussion  such  as  "does  the  access  transitive  property  stop  on  all 
lateral  links?" ,  "what  kind  of  bypass  links  can  be  ignored  in  the  mapping?" ,  and  so  forth. 

The  immediate  work  of  this  research  is  to  categorize  all  reasonable  assumptions 
comprehensively.  In  the  next  Chapter,  long  term  future  work  about  interdomain  access 
control  is  discussed. 


CHAPTER  6 
SUMMARY  AND  FUTURE  WORK 

This  dissertation  examines  security  and  efficiency  problems  of  interdomain  access 
control  (I AC)  across  heterogeneous  administrative  domains  (ADs).  With  different  admin- 
istrative policy  for  each  domain,  only  authenticated  and  authorized  packets  are  allowed  to 
flow  through  domain  boundaries. 

6.1  Summary 

My  first  contribution  for  interdomain  access  control  is  to  develop  a  key-based  and 
a  ticket-based  lAC  protocols,  which  integrate  the  underlying  policy  routing  facility  IDPR 
(Inter Domain  Policy  Routing).  These  two  protocols  build  a  communication  path  firom 
source  to  destination  and  solve  packet-dropping  problems  occurred  in  intermediate  nodes. 

For  communication  path  setup  efiiciency,  an  active  network  infrastructure  is  better 
than  current  TCP/IP.  My  second  contribution  is  to  develop  a  dynamic  path  setup  protocol 
in  an  active  network  environment  to  reduce  memory  overhead. 

Every  data  packet  flow  through  a  path  relies  on  a  session  key  for  authentication  and 

authorization.  Therefore,  the  secrecy  of  the  session  key  is  essential  for  interdomain  access 

control.  My  third  contribution  is  to  develop  a  generic  key  assignment  scheme  for  enforcing 

policy  exceptions  that  can  be  utilized  to  assign  keys  to  administrative  domains  so  that  the 

session  key  can  be  safely  distributed. 

6.2    Future  Work 

This  dissertation  proposed  several  lAC  protocols  utilizing  difierent  combinations 
of  static/dynamic  and  stateful/stateless  approaches  under  the  current  TCP/IP  and  the 
future  active  network  infrastructures.  Active  networks  are  a  novel  network  architecture  in 
which  each  switch  in  the  network  provides  a  computation  environment  such  that  customized 
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computation  can  be  performed  on  the  fly  based  on  the  messages  flowing  through  them.  In 
essence,  the  network  becomes  programmable  for  any  speciflc  apphcation.  It  is  a  revolutional 
concept  that  assumes  a  store-compute-forward  networking  paradigm. 

Active  networks  are  still  in  developing  stage  and  not  mature  enough.  In  order  to 
deploying  active  networks,  some  open  issues  need  to  be  discussed  comprehensively  and 
designed  carefully  such  as  secure  resource  management,  active  program  encoding,  efllicient 
active  node  architecture,  active  node  placement,  and  so  forth.  My  long  term  future  work 
is  to  study  the  security  issues  of  diverse  applications  under  the  active  network  prototype. 
Hopefully,  some  results  of  the  study  can  benefit  the  development  and  deployment  of  the 
active  network  infrastructiure  itself. 

Some  short  term  future  work  related  to  interdomain  access  control  are  listed  in  the 
following  sections. 

6.2.1    Neighbor  Selection  Criteria  in  Dynamic  Path  Setup 

The  dynamic  path  setup  protocol  described  in  Chapter  3  does  not  address  the 
neighbor  selection  criteria.  To  repair  a  failed  communication  session,  a  fast  path  repair 
process  is  crucial.  The  process  should  be  efficient  in  failure  detection  and  recovery.  The 
proposed  protocol  in  Chapter  3  achieves  fast  detection.  However,  failure  recovery  requires 
a  fast  detour  path  setup  and  relies  on  a  good  QNL  selection  criteria.  Each  router  in  the 
path  setup  protocol  has  no  knowledge  of  the  QNL  in  the  selected  next  router.  If  the  QNL  is 
empty,  a  Negative  Message  may  be  returned  and  cause  a  rewinding  of  the  search.  This  kind 
of  path  setup  rewinding  should  be  limited  by  a  good  selection  criteria.  One  way  to  decrease 
the  possibility  of  the  path  setup  rewinding  is  to  increase  the  information  available  to  each 
router.  For  example,  the  past  history  of  previous  path  setup  or  QNL  of  the  neighbors.  To 
make  this  information  available  to  each  router  may  slow  down  the  path  setup  in  another 
respect.  Therefore,  future  work  of  this  protocol  is  to  find  a  good  QNL  selection  criteria. 
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6.2.2  Multiple  Failures  in  Dynamic  Path  Setup 

Multiple  failures  is  another  issue  not  addressed  in  the  protocol.  There  may  be 
multiple  routers  detecting  different  failures  simultaneously.  It  is  not  a  good  idea  to  have 
multiple  path  repair  processes  running  at  the  same  time.  Simultaneous  repairs  may  result 
in  redundant  work  and  even  incorrect  path  repair  due  to  interference.  This  is  also  an  open 
area  to  be  addressed. 

6.2.3  Administrative  Policv  Encoding  and  Fast  Retrieval 

In  previous  chapters,  we  have  described  three  lAC  protocols.  All  of  them  are  trying 
to  find  a  path  so  that  all  the  involved  gateways  (routers)  can  satisfy  the  source  request 
service.  The  process  of  the  path  setup  actually  is  performing  the  eidministrative  policy 
match-up  among  source,  intermediate,  and  destination  domains.  The  questions  axe  what 
is  the  administrative  policy  and  how  the  policy  match-up  is  performed. 

Clark  [5]  suggests  that  each  policy  is  described  in  English  and  then  expressed  in 
a  Policy  Term  (PT)  notation.  Each  PT  encodes  a  distinct  policy  of  an  Administrative 
Domain  (AD)  that  synthesized  it.  The  form  of  a  PT  is: 

[{Hend,  ADend,  ADent),  {Hend,  ADgnd,  ADexit),  U CI,  Cg] 

where: 

Hend  is  the  source  or  destination  end  system, 
AD  end  is  the  source  or  destination  AD, 
ADent  is  the  traffic  entering  AD, 
ADexit  is  the  traffic  exit  AD, 
U CI  is  the  user  class  identifier, 
Cg  are  any  global  conditions. 

Each  PT  specifies  that  the  communication  is  allowed  between  two  specific  end  hosts  in 
two  domains  if  the  communication  traffic  is  entering  from  ADgnt  and  exit  through  AD  exit- 
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The  UCI  makes  PT's  more  fine-grained  from  host-based  to  user-based  and  Cg  concerns  all 
global  conditions  such  as  billing  or  quality  of  service  (QoS).  Note  that,  both  UCI's  and  Cg's 
should  be  globally  defined. 

The  exponential  growth  of  the  Internet  has  brought  diverse  users,  ADs,  and  appU- 
cations.  Therefore,  the  PT  should  be  powerful  and  flexible  enough  to  express  the  complex 
pohcies  in  the  current  highly  dynamic  Internet  environment.  The  PT  defined  by  Clark, 
above,  is  a  basic  form  and  definitely  not  enough  for  the  future. 

Not  only  is  the  PT  encoding  itself  important,  but  also  the  data  structure  of  PTs 
within  a  gateway  (router)  needs  further  study  so  that  the  retrieval  can  be  fast. 


GLOSSARY 

ACM  Access  Control  Matrix 

ACP  Access  Control  Policy 

AD  Administrative  Domains 

ASi  Accessible  Set  of  a  class  Ci 

CAP  Capsule 

DC  Directed  Graph 

COM  Computational  Complexity:  number  of  encryptions  and  decryptions 

DSi  Dominating  Set  of  a  class  Ci 

E(X,K)  Plaintext  X  encrypted  by  key  K 

FID  Forwarding  Information  Database 

H  Host 

lAC  Interdomain  Access  Control 

IDPR  InterDomain  Policy  Routing 

Ki  Secret  key  known  only  to  PGi 

Kij  Secret  key  shared  by  PGi  and  PGj 

Kg  Secret  session  key  for  a  traffic  flow 

KIAC  Key-based  Interdomain  Access  Control 

LAN  Local  Area  Network 

MAC  Message  Authentication  Code 


MAC(K)    packet's  Message  Authentication  Code  is  a  signed  message  digest  of 
the  packet's  contents  using  key  K 
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MAN  Metropolitan  Area  Network 

MTU  Maximum  Transfer  Unit 
n-system    A  system  with  n  distinct  user  classes 

NT  Nodes  Traversed 

NW  Network  Load:  number  of  packets  x  number  of  PGs  traversed 

PFP  Packet  Forwarding  Protocol 

PG  Policy  Gateway 

poset  Partially  Ordered  Set 

PR  Policy  Route 

PS  Path  Status 

PSP  Path  Setup  Protocol 

PT  Policy  Term 

PUP  Policy  Update  Protocol 

QNL  Qualified  Neighbor  List 

QoS  Quality  of  Services 

RID  Routing  Information  Database 

RSA  A  public  key  cryptographic  algorithm  developed  by  R.  L.  Rivest, 
A.  Shamir  and  L.  Adleman 

RT  Router 

SA  Security  Association 

SEC  Secret  Key  Searching:  number  of  secret  key  database  searches 

SES  Session  Key  Searching:  number  of  session  key  database  searches 

SKD  Session  Key  Database 
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SRS  Source  Requested  Service 

T^j,  (n-i+l)th  partial  ticket  generated  by  PGj  for  traffic  from  Ha  to 

2^  i-th  partial  ticket  generated  by  PGi  for  traffic  from  H},  to  Ha 

TIAC  Ticket-based  Interdomain  Access  Control 

UCI  User  Class  Identffier 

UM  User  Matrix:  A  matrix  represents  the  access  control  policy 

WAN  Wide  Area  Network 
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